Ok, we will see if this forum is needed or not...
I have a question for those experts on Sedoric... As you might already now I am trying to copy data from disk and put it in overlay ram. I am using my own disk access routines (sector based) for that purpose.
The question is that I supposed that we could use all the overlay ram for the game, as we can get rid of the OS once the program is running, so I started puting all the world map data from $c000 upwards, with the surprise that it did not work.
Then I started in $c010 and it worked IF I load just 2560 bytes (just a test, not a real limit). Else I got something like a BREAK error on an upper address (from the overlay ram, that is). So somehow the processor was executing code there
But the most impressive thing is that even loading part of the map and running the game I noticed some keys did not work, among other strange bugs that either hanged the program or exit to BASIC. When in BASIC I realized why some keys didn't work... I had my keyboard in AZERTY mode
So, what I am doing wrong? Of course during program execution I supposedly switch rom in again to perform things like getting keypresses and some sounds by issuing jsr $04f2 and it remains on until another room has to be loaded. If the OS is doing something I don't know with an IRQ, how can I disable that? Sometimes, when I press F11 the processor is executing code in page 4, that is for sure.
Also I don't have a Sedoric manual... how could I create an empty formatted bootable disk without any 'nice' features? I just want to CLOAD my program, once the OS booted.
Help!
Space99 - disk access and overlay ram
Ok, as maybe you read on the general thread, all the problems are gone (nearly) once we switched from the system's irq to Twilighte's...
However I still have some problems and need some help with them:
I would need a way to create a Sedoric disk with the minimal OS to boot, the game and data stored on the upper sectors. I don't think this can be automated, so I guess it will be enough with a Sedoric disk with the minimal OS so it boots. I will store data on the empty space of the disk, use it to boot and cload the program from the tap file manually.
On a more technical side I am still unable to read/write the whole 512 bytes of each sector, just 256 and have no idea why. Also I have code for disk access that seems to work for Microdisc, Jasmin, Oric and Telestrat at least. This comes from the latest version of Pinforic and has something like this (this is from the file header.s)
where switch_to_x does not anymore use a vector on page 4, but different code depending on the machine_type that seem to work with Jasmin and Microdisc. IRQ routines for disk access are also different and all this code is specific for Pinforic and even used another assembler.
I don't understand most of it
I am trying to keep code only for working with Microdisc (older routines), but maybe this would be interesting to have a look at, if you want it to be included in OSDK...
However I still have some problems and need some help with them:
I would need a way to create a Sedoric disk with the minimal OS to boot, the game and data stored on the upper sectors. I don't think this can be automated, so I guess it will be enough with a Sedoric disk with the minimal OS so it boots. I will store data on the empty space of the disk, use it to boot and cload the program from the tap file manually.
On a more technical side I am still unable to read/write the whole 512 bytes of each sector, just 256 and have no idea why. Also I have code for disk access that seems to work for Microdisc, Jasmin, Oric and Telestrat at least. This comes from the latest version of Pinforic and has something like this (this is from the file header.s)
Code: Select all
org $500
sta _machine_type
and #$80
bmi init_telestrat
lda #$22
sta $026A
lda #0
sta $026B
lda #7
sta $026C
jmp machine_dependant_done
init_telestrat
machine_dependant_done
jsr switch_to_ram
jsr _init_disk
cli
lda #$C0
sta $030E
lda #$40
sta $030B
jsr go_main
jsr switch_to_rom
I don't understand most of it
I am trying to keep code only for working with Microdisc (older routines), but maybe this would be interesting to have a look at, if you want it to be included in OSDK...
I have read your message very quickly, so sorry if my reply doesn't help with your problem, but standard Sedoric sectors only hold 256 bytes.On a more technical side I am still unable to read/write the whole 512 bytes of each sector, just 256 and have no idea why
Pinforic is something very special IIRC, and may have been modified to read special disks with 512 bytes per sector. The Oric hardware was physically able to do so (I recall a video showing some disk editors allowed to view MS-DOS disks sectors, with 512 bytes by sector).
I think that Simon is right on this.
In the Sedoric and microdisc manual (http://www.defence-force.org/computing/ ... /index.htm) there is an indication that the INIT command supports between 16 and 19 sectors per track. Each sector being 256 bytes long.
The disk controleur and drive themself support 512 bytes long sectors, and it's a format that Fabrice tend to like because it can be made compatible with MSDos.
In the Sedoric and microdisc manual (http://www.defence-force.org/computing/ ... /index.htm) there is an indication that the INIT command supports between 16 and 19 sectors per track. Each sector being 256 bytes long.
The disk controleur and drive themself support 512 bytes long sectors, and it's a format that Fabrice tend to like because it can be made compatible with MSDos.
Thanks for your answers. Yes, indeed that is the point. I did not remember that pinforic disks were MSDOS, so sectors were 512 bytes. Fabrice remembered me that just this weekendDbug wrote:I think that Simon is right on this.
In the Sedoric and microdisc manual (http://www.defence-force.org/computing/ ... /index.htm) there is an indication that the INIT command supports between 16 and 19 sectors per track. Each sector being 256 bytes long.
The disk controleur and drive themself support 512 bytes long sectors, and it's a format that Fabrice tend to like because it can be made compatible with MSDos.
About adding the routines to the osdk, I can provide the assembly code, even if I don't understand it completely.
Cheers.