SEDORIC in C

Since we do not have native C compilers on the Oric, this forum will be mostly be used by people using CC65 or the OSDK. But any general C related post will be welcome !
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

SEDORIC in C

Post by xahmol »

Are there any libraries/examples for the use of SEDORIC in C?

Looked at the C libraries in OSDK and see that lib.h has only very minimal support for SEDORIC, only void sedoric(char *command); to send a command. The rest of the disk API is still work in progress I see.
This works for a LOAD at least (the only thing I tried so far), sedoric("!LOAD \"LUDOSCRM.BIN\""); does perfectly load that file. But I see no error handling whatsoever is implemented. Also 'Bear in mind that this might well be broken' does not exacly inspire confidence in using it.
Also looked at CC65, but documentation there indicates no disk support whatsoever is implemented for the Atmos, so even less than that one command in OSDK.

At least the LOAD is workable, as it appears to work without any issue. And can live without error handling there, if the end user janks the disk out or shuts of the disk drive, I think that end user can also rightfully expect that no error handling for that is in place.
But for save games this is more an issue. In my BASIC LUDO game, I implemented minimal error handling to at least check if a save game with the same name is already present by the SEARCH SEDORIC command.
I guess I can still pass the SEARCH command via sedoric();, but that is of little value if the output of that command is not returned. In BASIC it is returned by the EF value, but is there any way to retrieve that same value via C and the sedoric(); command? Is there a memory position somewhere which I can read with that EF variable value?
Can live without the ERR SET: ERRGOTO command for the rest. Again, if the user janks the disk out or saves so many save games the disk is full that is than not prevented, but a too minimal use case in my opinion to be really bothered with. But that file present check to ask for confirmation if you really want to overwrite or give feedback if you made a typo in the name loading a save game is I think needed at least.

Any ideas/suggestions?

Otherwise I think I might go with only one fixed save game file (so no typos can be made and so the file is always overwritten on a new save), or a slot system with 5 fixed save file names and a variable in the save file to see if it is empty or not.
Just hope than that passing a SAVEO command via sedoric("!SAVEO \"<filename>\",A#<startadress>,E#<endaddress>"); works as well.

(Background: Now in the process to try to convert my BASIC code for my LUDO game to C using OSDK. Have my menu system working fine now in C, so apart from the SEDORIC commands I seem to progress well. So will not provide a new game yet, started to port an existing game for learning mainly. But obviously I hope that the LUDO game will also benefit from the speed C gives compared to BASIC).

Lastly, two not SEDORIC related C questions that (for now) I do not want a seperate topic for as they are probably n00b questions:
- My work in progress C code runs well, but on exit it gives a syntax error as apparently the BASIC interpreter starts interpreting the machine code. LIST gives garbage. Am I doing something wrong here? Have SET OSDKADDR=$500, will another start address help? Other solutions?
I have some recent experience in C compiling with CC65 with my Commodore 128 as target, but there the output gives a small BASIC program calling the machine code loaded next to it in the same file. On exit, it returns to a normal BASIC prompt and you can then choose to RUN the program again. Is something similar possible in OSDK?
Having a syntax error on exit looks very clumsy, so really want to avoid that.

- What is the latest verdict in the OSDK vs CC65 discussion on what is better on which areas? See a couple of posts on the forum, but they are already quite old, and are also inconclusive in conclusion (CC65 smaller code, but OSDK faster code?). Went with OSDK for now as I tend wanting to standardise on what the community does. Also, at least OSDK has one SEDORIC command more than CC65 without need for importing external things.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: SEDORIC in C

Post by xahmol »

Searched before and did not find this, but searched again and now see this post:
https://forum.defence-force.org/viewtop ... 561#p18561

I assume I can include that lib in OSDK as well instead of just CC65? Will give that a try as these functions actually do return an error message I see, so I assume that then the program can detect a file not found.

Sound like usable for my needs, so apparently @iss answered my question before I even posted it ;-)

Any plans on expanding this lib with for example the SEARCH command just checking if a file exists before actually loading it?
Last edited by xahmol on Thu Jan 28, 2021 2:24 pm, edited 1 time in total.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: SEDORIC in C

Post by Dbug »

xahmol wrote: Thu Jan 28, 2021 9:16 am Are there any libraries/examples for the use of SEDORIC in C?

Looked at the C libraries in OSDK and see that lib.h has only very minimal support for SEDORIC, only void sedoric(char *command); to send a command. The rest of the disk API is still work in progress I see.
This works for a LOAD at least (the only thing I tried so far), sedoric("!LOAD \"LUDOSCRM.BIN\""); does perfectly load that file. But I see no error handling whatsoever is implemented. Also 'Bear in mind that this might well be broken' does not exacly inspire confidence in using it.
Also looked at CC65, but documentation there indicates no disk support whatsoever is implemented for the Atmos, so even less than that one command in OSDK.
This command came with the original SDK the OSDK is based on, so that was pretty much never changed in the last 20 years, so your guess is as good as mine.

tldr; I don't use Sedoric (that's why I made the floppy builder), so you need other people to help.

If you can come up with something better, I can add it to the OSDK :)

- My work in progress C code runs well, but on exit it gives a syntax error as apparently the BASIC interpreter starts interpreting the machine code. LIST gives garbage. Am I doing something wrong here? Have SET OSDKADDR=$500, will another start address help? Other solutions?
$501 is where the BASIC starts, but on small tests it did not seem to corrupt anything.
Are you altering anything in page 0 and page 2?
- What is the latest verdict in the OSDK vs CC65 discussion on what is better on which areas? See a couple of posts on the forum, but they are already quite old, and are also inconclusive in conclusion (CC65 smaller code, but OSDK faster code?). Went with OSDK for now as I tend wanting to standardise on what the community does. Also, at least OSDK has one SEDORIC command more than CC65 without need for importing external things.
You probably want to read that:
http://eab.abime.net/showthread.php?t=103036

As far as I'm concerned, CC65 will never be part of the OSDK, but VBCC may.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: SEDORIC in C

Post by Chema »

Oh my! I did not know you were in conversations for a oric version of vbcc! That sounds terrific. I skimmed through the posts and it looks incredible!

I only hope passing arguments to a C function from asm and getting the result back is compatible with what we are doing now in LCC65, or easy to adapt, because I suppose they use some kind of C stack and get the results on a pair of registers...

And may I just request something? Support for the wonderful .( .) notation in XA. I absolutely love it. I don't care if they change it for {} or begin/end, but multi-level locals are a bless. You probably noticed that I almost always start writing my asm routines as:

Code: Select all

MyRoutine
.(

.)
I use this notation to give scope, even if no local labels are necessary, but I have not seen any other assembler that supports multi-level locals, and that is incredibly convenient when repeating sections due to loop unroll or repetitive loop operations:

Code: Select all

MyRoutine
.(
 	Some fantastic code here
  	
  	ldy #whatever
.(
 loop
 	sta $dead,y
	dey
	bne loop
.)

	More fantastic code here

	ldy #anotherthing
.(
 loop
 	sta $123,y
	dey
	bne loop
.)

.)
without having to write loop1/loop2/loop3...
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: SEDORIC in C

Post by xahmol »

Dbug wrote: Thu Jan 28, 2021 2:23 pm $501 is where the BASIC starts, but on small tests it did not seem to corrupt anything.
Are you altering anything in page 0 and page 2?
Not that I am aware of. Did not allocate any memory area myself yet apart from loading a screen into the text memo area and charsets in the charset memory area. For the rest did nothing special and only using lib.h functions. But given your response I guess I have to check if I am messing up memory somewhere with a bug or something stupid I did.
Funny thing is it was OK at first, but suddenly started giving this issue when the programme growed some more. And that the samples in the OSDK package indeed have none issue whatsoever.
Last edited by xahmol on Thu Jan 28, 2021 4:31 pm, edited 1 time in total.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: SEDORIC in C

Post by xahmol »

Dbug wrote: Thu Jan 28, 2021 2:23 pm As far as I'm concerned, CC65 will never be part of the OSDK
Just curious, as I really have no basis for any opinion on this, why? Ask as CC65 seems to be the defacto standard for every other 6502 8 bit....
VBCC looks nice by the way if I see the list of advantages.

EDIT: Never mind, the thread you linked does indeed explain. Thanks. (and yes, should start reading before replying next time ;-) )

Personally have no preference yet for any compiler whatsoever, and for my needs probably all compilers will do the trick with code that gives a huge speed bump over BASIC. Machine code apart from small and simple stuff for me is still a step to far.
So primarily looking for the IDE that is most supported for C on the Oric giving me the best/broadest support of Oric libraries.
And I also now understand your reasons not to choose CC65, but also see that all these reasons are not yet relevant for my use case as long as I keep steering away from assembler code ;-) So maybe will give CC65 a try as well.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: SEDORIC in C

Post by xahmol »

Update: I commented the sedoric(); command and now do no longer have a syntax error on exit. So while the command in game was working perfectly, it apparently has strange side effects (or I have misprogrammed it). So that is maybe the ''Bear in mind that this might well be broken' part.
(so the syntax error actually was on topic in this thread).

Will move to the small lib from Iss as mentioned above and see if that helps/works.
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: SEDORIC in C

Post by jbperin »

Chema wrote: Thu Jan 28, 2021 3:50 pm Support for the wonderful .( .) notation in XA. I absolutely love it.
+1

PS: Sorry, I know nothing about SEDORIC so i can't help.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: SEDORIC in C

Post by xahmol »

By the way: I am certainly not married to SEDORIC, just something that works and can be used in C with OSDK.
So if there are other brilliant ways to load text screens, charsets and save games with error handling, I am absolutely interested. But so far see also no other disk implementation in the OSDK C libs (or the CC65 ones for that matter) other than the one I just found on this forum from ISS.

Is everybody else here that makes DSK games doing so purely in assembler then?
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: SEDORIC in C

Post by Chema »

xahmol wrote: Thu Jan 28, 2021 6:48 pm By the way: I am certainly not married to SEDORIC, just something that works and can be used in C with OSDK.
So if there are other brilliant ways to load text screens, charsets and save games with error handling, I am absolutely interested. But so far see also no other disk implementation in the OSDK C libs (or the CC65 ones for that matter) other than the one I just found on this forum from ISS.

Is everybody else here that makes DSK games doing so purely in assembler then?
In fact, yes. I used SEDORIC to boot and load the game and, from there after, only sector-based read/write routines (which are available in the sources of my games). For Blakes'7 I even moved to the wonderful FloppyBuider, which creates a custom floppy with no filesystem or OS whatsoever: simply read/write routines based on sector and size (and including compression).

The learning curve might be steep, but once you get used to it, it is much better to get rid of the OS and keep those 16K of overlay ram for your program instead.

If you want to keep your game with SEDORIC, you need to create a binary with all the data, note down the sectors and sizes and create a custom disk with tap2dsk so you know where data starts on this disk. Then use read sector and write sector routines (for writing out of the used area). If you go for FloppyBuilder, read the OSDK documentation here and also note that I added write support for saving a game for Blake's 7 (albeit just one savepoint, as it saves automatically - but it could be extended to save-slots as I did in 1337).
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: SEDORIC in C

Post by ibisum »

Check out also, ~twilighte/Wurlde/DiscCode, wherein you can find C-callable sector read/writes with little effort:

Code: Select all

;Modify boot routine to load sector2 into FD00-FEFF then jump FE09
;	+17C,$FD
;	+5C,$4C
;	+5D,$09
;	+5E,$FE
#define fdc_Command     $0300
#define fdc_Status      $0300
#define fdc_Track       $0301
#define fdc_Sector      $0302
#define fdc_Data        $0303
#define fdc_Control     $0304

#define	FATSectorFlags	$FF00
#define	FATSideTrack	$FF50
#define	FATSectorSize	$FFA0
#define	DiskTracks	$FFF0
#define	Version		$FFF1
#define	DiskSectors	$FFF2
#define	FDC_Offset	$FFF3
#define	MachineType	$FFF4
#define	FirstFileLoadHi	$FFF5
#define	SectorCount	$FFF6
#define	FirstFileExec	$FFF7
;$47 FDC Offset
;	$10	Microdisc/Telestrat
;	$F4	Jasmin
;$00 Machine Type
;	$20	Jasmin
;	$40	Atmos Microdisc Controller
;	$C0	Telestrat

;Sector 2 Structure
;FD00-FDF9 File Address Tables
;
;FE00 - JMP Load Datablock
;FE03 - JMP Save Sector
;FE06 - JMP Set Drive
;FE09 - Transfer FD00-FDF9 >> FF00-FFF9
;	Transfer FDC Offset($47) to FFF3
;	Transfer Machine Type($00) to FFF4
;	Initialise Loading first data block
;FEXX - GR - Load DataBlock
;FEXX - GR - Save Sector
;FEXX - GR - Set Drive

 .text
*=$FD00

;FD00-FDEF(FF00-FFEF)
;First half of sector (240) holds FAT Table which is organised
;into 80 x 3 byte records..
;+00 Sector
;	Bits 0-4 Sector(0-31)
;	Bits 5-7 Future Flags
;+01 Side/Track
;+02 Number of Sectors
tFATSectorFlags	;Generic512 Offset +00
 .dsb 80,1
tFATSideTrack	;Generic512 Offset +80
 .dsb 80,0
tFATSectorSize	;Generic512 Offset +160
 .dsb 80,0

;FDF0(FFF0) Number of Tracks/Sides on Disc
tDiskTracks	;Generic512 Offset +240
 .byt 1+82*2

;FDF1(FFF1) Version
tVersion
 .byt 1

;FDF2(FFF2) Number of Sectors Per Track Plus One
tDiskSectors	;Generic512 Offset +241
 .byt 10

;FDF3(FFF3) FDC Offset
tFDC_Offset
 .byt 0	;Set in FEXX Routine

;FDF4(FFF4) Machine Type
tMachineType
 .byt 0	;Set in FEXX Routine

;FDF5(FFF5) First File Load Address High
tFirstFileLoadHi	;Generic512 Offset +244
 .byt $04	;Set in DSKBuilder

;FDF6(FFF6) Temporary location for Counting the total Sectors to Load
tTempDrive
tSectorCount
 .byt 0

;FDF7-FDF8(FFF7-FFF8) First File Exec Address
tFirstFileExec	;Generic512 Offset +246/7
tDriveNumber	;
 .byt $00
 .byt $04	;Set in DSKBuilder

;FDF9(FFF9) Number of Files on Disk (Excludes Boot Sectors 1 and 2)

 .byt 0		;Generic512 Offset +248

;FDFA-FDFF Wasted space

 .byt "Twi-08"

;FE00 - JMP Load Datablock

	jmp LoadDataBlock

;FE03 - JMP Save Sector

	jmp SaveSector

;FE06 - JMP Set Drive

	jmp SetDrive

;FE09 - Transfer FD00-FDF9 >> FF00-FFF9
;	Transfer FDC Offset($47) to FFF3
;	Transfer Machine Type($00) to FFF4
;	Initialise Loading first data block

InitialiseFirstLoad
	; Transfer FD00-FDF9 >> FF00-FFF9
;.(
;loop1	lda #65
;	sta $bb80
;	jmp loop1
;.)
	ldx #$FA
.(
loop1	lda $FCFF,x
	sta $FEFF,x
	dex
	bne loop1
.)
	; Transfer FDC Offset($47) to FFF3
	lda $47
	sta $FFF3

	; Transfer Machine Type($00) to FFF4
	lda $00
	sta $FFF4

	; Initialise Loading first data block
	lda FirstFileLoadHi
	ldx #00
	jsr LoadDataBlock
	;Reset Stack
	ldx #$FF
	txs
	jmp (FirstFileExec)

LookupFAT
	;Fetch and Store Side
	;Jasmin - $3F8 Bit 0
	;Microdisc - $314 Bit 4
	lda FATSideTrack,x
	and #01
	bit MachineType
.(
	bvc skip1
	asl
	asl
	asl
	asl
	ora #$84
skip1	sta $0304,y
.)
	;Fetch and Seek Track
	lda FATSideTrack,x
	lsr
	sta fdc_Data,y
	lda #%00011000
	sta fdc_Command,y
	jsr WaitOnCommandEnd
	;Fetch and store Sector
	lda FATSectorFlags,x
	sta fdc_Sector,y
	;Fetch and store Sector Size
	lda FATSectorSize,x
	sta SectorCount
	rts

ReadSectorHalf
RSHLoop	lda fdc_Status,y
	and #%00000010
	beq RSHLoop
	lda fdc_Data,y
Vector1	sta $DE00,x
	inx
	bne RSHLoop
	inc Vector1+2
	rts

WaitOnCommandEnd
	lda fdc_Status,y
	lsr
	bcs WaitOnCommandEnd
	asl
	and #$1C
	rts

;FEXX - GR - Load DataBlock
LoadDataBlock
	php
	sei
	;Store parsed High Load Address
	sta Vector1+2
	;Locate address
	ldy FDC_Offset
	jsr LookupFAT
	;
	ldx #00
	;Read Sector
.(
loop3	lda #$84
	sta fdc_Command,y
	jsr ReadSectorHalf
	jsr ReadSectorHalf
	jsr WaitOnCommandEnd
	;Error Check
	beq skip2
	dec Vector1+2	;Reload Sector
       	dec Vector1+2
	jmp LoadDataBlock
skip2	;Progress Sector
	lda fdc_Sector,y
	clc
	adc #01
	cmp DiskSectors
	bcc skip1
	;Progress Track
	lda #$5B
	sta fdc_Command,y
	jsr WaitOnCommandEnd
	lda #01
skip1	sta fdc_Sector,y
	;Progress Sector Count
	dec SectorCount
	bne loop3
.)
	plp
	rts

;FEXX - GR - Save Sector
SaveSector
;FEXX - GR - Set Drive
;X - Drive 0-3
SetDrive
	lda tFDC_Offset
	;$10	Microdisc/Telestrat
	;$F4	Jasmin
.(
	bmi SetJasminDrive
SetMicrodiscDrive
	lda $314
	and #%10011111
	ora DriveBitPair,x
	sta $314
	jmp rent1
SetJasminDrive
	sta $3FC,x
rent1	stx tDriveNumber
.)
	rts
DriveBitPair
 .byt %00000000
 .byt %00100000
 .byt %01000000
 .byt %01100000

 .dsb 256-(*&255)
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: SEDORIC in C

Post by xahmol »

ibisum wrote: Fri Jan 29, 2021 4:53 pm Check out also, ~twilighte/Wurlde/DiscCode
Thanks. Have the code from Iss working now (with Iss kindly noting me a small bug in the version that was in the post I linked), think I will use that at least now as it looks easier to grasp than this one. Will definitely check this one sometime if I want to do more complex stuff.
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: SEDORIC in C

Post by iss »

Chema wrote: Thu Jan 28, 2021 3:50 pm Oh my! I did not know you were in conversations for a oric version of vbcc! That sounds terrific. I skimmed through the posts and it looks incredible!
This is very interesting and I think it deserves further discussions in the dedicated thread.

I've uploaded updated (and optimized) version: https://github.com/iss000/oricOpenLibra ... ib-sedoric
as part of my oricOpenLibrary :).
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: SEDORIC in C

Post by xahmol »

Thanks, Iss! Very helpful.

Meanwhile busy with also giving CC65 a try for Oric. If it really seems to provide code that is 50% smaller, that is worthwhile to look into.
Understand Dbugs reasons for not using CC65, but I will not be using the assembler anyway (apart from importing stuff from others like Iss).
Curious what the result will be comparing sizes. For what I am programming now I think the speed difference is not really an issue as probably both will be fast enough to not notice the difference unless you exactly time. Game logic is not so complex that I can imagine any difference will be noticeable and I am programming a board game strictly in text mode, so not exactly the type of game where screen refresh rate and such is an issue, but we will see.
Using CC65 under Linux in Windows Subsystem for Linux (as the project I did on the 128 was based on sources with Linux make files that was quicker, also had lot of compile issues under the CC65 Windows version with that codebase), so I guess one makefile for CC65 in Linux and the OSDK tools under Windows in that setup will not be possible. Or at least not practical as I would then need to run Wine under Windows Subsystem for Linux to use OSDK under WSL.....

Has also the added benefit is that using the code base also for the Commodore 128 is less work. Original is in C128 BASIC, might port back to C128 in C as well. For me the code does not need to be platform independent (as that always sacrifices optimisation for target and therefore prefer to have two seperate code bases), but for example using conio.h and string.h instead of the OSDK lib.h already saves a lot of work reusing the code.

See by the way that CC65 actually already includes joystick drivers for the Atmos (PASE and IJK). Like the work DBug has done on supporting literally all joystick interfaces out there, but as everybody seems to move to IJK, is there a real need to program for anything else? (Joystick support in a board game is already a nice to have and not need to have anyway, but like using the IJK Egopad for controlling my pull down menu system).
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: SEDORIC in C

Post by Dbug »

xahmol wrote: Sat Jan 30, 2021 1:49 pm Meanwhile busy with also giving CC65 a try for Oric. If it really seems to provide code that is 50% smaller, that is worthwhile to look into.
Understand Dbugs reasons for not using CC65, but I will not be using the assembler anyway (apart from importing stuff from others like Iss).
I would not recommend using the OSDK for any large C program.
We've tried to fix the compiler, Laurent, me and other spent some time trying to reproduce some issues and fix them, but I don't see how possibly one man (Fabrice) can improve such an old compiler to the point it would be competitive.

I've not started anything yet, but I guess my next step is to tell him that maybe we should just drop it and invest the time in something better.

For all it's inferiority in 2021, LCC65 was what kickstarted the Oric come back around 1995, and for that I'm very grateful.
xahmol wrote: Sat Jan 30, 2021 1:49 pm See by the way that CC65 actually already includes joystick drivers for the Atmos (PASE and IJK). Like the work DBug has done on supporting literally all joystick interfaces out there, but as everybody seems to move to IJK, is there a real need to program for anything else? (Joystick support in a board game is already a nice to have and not need to have anyway, but like using the IJK Egopad for controlling my pull down menu system).
Me supporting everything is more like my way of saying that: Yes, some of you have old hardware, and you can use it if you want.
Post Reply