16k Oric-1

Comments, problems, suggestions about Oric emulators (Euphoric, Mess, Amoric, etc...) it's the right place to ask. And don't hesitate to give your tips and tricks that help using these emulations in the best possible way on your favorite operating system.
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron »

Well, with recent changes, SEDORIC based disks don't try and read invalid sectors and tracks any more, but they do all end up executing empty RAM (i.e. lots of BRKs) at around $D000. I know that SEDORIC places code in the overlay RAM, but it seems most of the overlay RAM is just zeros. I've checked and double checked and my implimentation of the ROMDIS and EPROM lines should be correct...
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

That's kind of strange.
Technically (for what I know), the only difference between all these operating systems is just what they provide as functionalities and the high-level system.

Could it be an issue with the support of the size of sectors? I seem to remember that some (possibly Randos) try to be more or less msdos compatible by using 512 large sectors, while Sedoric typically uses 256 bytes large sectors.

Do you handle both?
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron »

Yes the sector size is correctly read from the disk image..
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Ok, something you could try, is one of the demos, like Barbitoric.

Basically all they did is to have the controler eprom read the boot-sector somewhere in memory (this boot sector was written by Jede and I), which then switch to the overlay memory, and load the actual loaded on the top of memory.

Would probably be easier to debug than a complete OS, and it uses the Sedoric disk as a base. You can get it there:

http://pouet.net/prod.php?which=8558
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

As far as i recall OricDOS doesn't use interrupts in the boot whereas Sedoric does. Interruptless programming permits a far better control over the boot imho. I used it in the Wurlde boot disk which you should find over in the Wurlde forum. :)
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron »

I don't know that it is an interrupt problem; neither sedoric or oricdos work, and I have a feeling its the same fault with both (they both seem to end up executing incorrect code). From the emulators perspective, the interrupt stuff is quite simple, the disk controller generates an interrupt at the completion of each command.

Weird that randos works perfectly, though.
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron »

Incidentally, Wurle ends up executing nonsense as well.

BTW, if anyone who knows more about the oric side of the disk stuff wants to help track down where things are going wrong, oriculator's debugger is pretty good. I'll put up a new WIP build tomorrow.
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron »

Well, its midnight, so technically it is tomorrow :-)

I've put up a windows build with the almost-working disk support. RANDOS works great, for example.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Best luck with this... I can't help, myself. Though I use sector-based access and overlay ram in my programs, I don't know how things work on the hardware side...

Maybe it is a stupid remark, but it is strange that you are executing code in an empty area... Check if there is actually something in the overlay ram (code MUST be there), or if it is just empty. I doubt there is an error there. Maybe what the code is trying is to run something in the EPROM, which should mask overlay ram as well as rom... am I right, or completely confused?

Probably confused as EPROM is hardware dependant, so can't see why some DOS would work while other does not.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Well, the zeros are in the overlay memory, not in the eprom, so for some reason after the boot sector has been loaded, the result of loading the operating system to the overlay ram fails. Could be a number of reason:
- the emulator refusing to write data from C000 to FFFF due to some rom checkl
- could be the overlay switch itself failing which would then write to ROM instead, leaving the ram untounched
- could be the read from the disk, which using some code/timings work (which would explain the boot sector and some os to work fine) but would just return 0 on some other type of sector loading code

Since Randos is working, we can exclude a number of these issues, or if they are, they are victim of a random occurence (possibly non initialized variable somewhere).
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Ok, I spent some time trying to get the information about the disk file format, gathering some stuff from the source code of oric2mfm, some in sedoric a nu, some from the ceo mag. I'm not quite sure everything is correct, and apparently the crc data is not commented the same way in the various sources I found, but here is what I found, correct me if I'm wrong :)

http://wiki.defence-force.org/doku.php? ... isk_format
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Yeah, Dbug. You are right. It should be quite easy to see this, though. If the overlay ram is not switched in, you should see the ROM code in the upper 16K. If nothing can be copied there as you point out, then you should see the upper 16K filled with zeros, am I right? I thought that maybe the other DOSes could do some kind of switch between ROM, overlay RAM and/or EPROM in the process, which could be buggy.

Anyway the third reason you mention could be the right one.

Good luck with this...
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Hi,

Just a quick post to say that I compared the contents of the overlay ram in oriculator and euphoric just when loading space:1999 and i found something interesting.

After the first run in oriculator, overlay ram seem to contain part of the OS, but not all. Most is empty, but, for instance you can see strings like systemdos or bootupcom around c010. There seems to be code in c400 up to c800. Nothing new here. From there on, all is empty, so jumping to D100 (around there) issues a BRK which is not attended and SP just overflows again and again.

If you issue a reset in oriculator, things are different. There is a lot of data in overlay ram, including the file list. There are differences from what I see in Euphoric, as I cannot stop them at the same point (in Euphoric i still see the systemdos and bootup com things around c010). But there is indeed the same code before d102, then a bunch of zeros in oriculator where other code should be, up to d200, where the same data in both emulators can be seen.

The thing that after a reset, more data appears in overlay should be a clue. Also the fact that there is nearly a page is missing there and that the system behaves differently after a reset. In fact brks run a IRQ service code, that is why the system ends up in an infinite loop.

I know this is just a bunch of possibly irrelevant data, but hey... just in case it rings bells on somebody's brain :)
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron »

Good work! Thanks for your help. Interesting that it is different after a reset.
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron »

I think the sedoric problem may be the same thing that stops the record player effect working in barbitoric; in both cases it seems to be the copying of data that fails.

BTW, I've uploaded a new build of oriculator that has some suggested improvements to the memory watch window in the debugger.

Hit 'S' to split the memwatch in two, and use TAB to toggle between the two memwatch windows.

Also, changed bytes are highlighted.
Post Reply