Cumulus and Sedoric 3
Posted by retromaster on November 25, 2010
-
- Cumulus in Operation (1)
-
- Cumulus in Operation (2)
-
- Cumulus in Operation (3)
-
- Cumulus in Operation (4)
-
- Cumulus Rev A Closeup
In my post yesterday, I had said that Sedoric 3 disks were not working with Cumulus. Actually, that turned out not to be true, due to a stupid mistake on my part (mostly due to my being not very familiar with the Oric software environment).
The disk images I was trying to get to boot were actually “slave” disks, so they were not bootable at all. Since I had never tried those disks on an emulator (and never had a real Microdisc unit), the “DOS is altered” message misled me into thinking that Cumulus was at fault.
So, booting first with a Sedoric 3 Master disk gave the results in the shots above. To be able to switch disk images, I implemented a rudimentary method that goes through all images in the root directory of the SD card on press of a button.
Now that the basic functionality is working, it’s time to think about where to go next:
0. There is still a bug (probably with the Oric bus) that causes occasional boot failures or crashes. This is much less in frequency than before, but it still needs to be fixed of course.
1. There are quite a few commands missing from the WD179X implementation on the PIC. Also the whole behaviour of the floppy emulator could be made more “floppy-like”, with more accurate timings, for example. Multiple drive support is possible.
2. A proper UI that makes use of the LCD and buttons is part of the specs.
3. A new PCB design that consolidates all existing design elements into a compact, single board, and fixes existing problems (couple of missing traces, etc.) is necessary.
Retromaster's Electronics Projects 
Gokhan said
You are truly Retromaster…
Dbug said
Awesome 🙂
I see on the photos that all the software you tried is actually using standard operating system routines to access the floppy, you may want to give a try with some other software that access the floppy controller using their own code (mostly so they can use the 16k of overlay memory for their own pleasure).
Suggestions:
– “Space:1999” and “1337” (you can find them at http://space1999.defence-force.org and http://1337.defence-force.org)
– Some of the demos like VIP4/Quintessential (http://www.defence-force.org/computing/oric/dbug/vip_4/index.htm) and Barbitoric (http://www.defence-force.org/computing/oric/dbug/barbitoric/index.htm)
Advantage of testing on demos is that they are doing continuous loading of various parts, so if there is anything wrong in the way the overlay/irq/loading works, they will complain 🙂
Something to know as well, there are two ways of loading stuff from the disk on the Oric, the IRQ method, and the register polling method. The first one is the most commonly used, the second one is the smartest way because instead of spending all the time in the IRQ you can actually do something while waiting for bytes (like animating something on screen, copying data, playing audio, etc…)
retromaster said
Thanks for the suggestion. Actually I had testing with demos in mind too but somehow I’ve forgotten mentioning it in my roadmap… Anyway, I did not know which demos would bypass the OS for disk operations… Now I have a kind of “test bench” :).
One of the major advantages of having a full-fledged 1793 emulator is full compatibility with existing software (that is written for the Microdisc in this case). It would have been significantly easier to just design some kind of direct SD card interface, but then one would definitely lose compatibility.
I hope I can ask for your help during debugging if I run into some kind of problem during testing with these demos. Nothing major, perhaps I may just ask for disassembly of a piece of the loader code just to be able to follow things. Hopefully, I won’t need it… 🙂
Dbug said
Sure, that should be doable.
We have the source code of 1337 and space 1999 easily available on the SVN server:
http://miniserve.defence-force.org/svn/public/oric/games/Space%201999/Sources/game%20source/disk.s
http://miniserve.defence-force.org/svn/users/chema/1337intro/disk.s
For the demos, they are a bit old, have to check in my archives for the loader part (was not me writing it, so I may have some versions of the loader, just not sure I have the exact version that was bundled on these released demos).
retromaster said
I am quite sure that stuff will come in handy, thanks. I’ll probably test with those images tomorrow evening or during the weekend, and see what happens.
This evening I had a chance to try out digitally generating the Oric bus related signals (like MAP) in the CPLD to see if could get rid of the 74221 and the RC delay circuitry. I managed to get it to work :). This already seems to have made Cumulus more stable. I’ll test some more and post more details on the blog later.
-RM
Mark McDougall said
Nice work!
Are you planning to implement the track commands? Are you going to support formatting disk images from the Oric? How are you going to handle inter-sector track formatting data?
When I was implementing my 179X in an FPGA for the TRS-80, I found that the TRS-80 disk utility software appeared to be writing invalid track data – too short IIRC – at the start and between each sector, according the to WD179X data sheet. Interesting to see if you come across the same issues…
retromaster said
Thanks. I do intend to implement track commands (see roadmap item #1 😉 ).
The interesting thing about the Oric DSK format is that, it does actually contain all of the bytes on a track (gaps, address marks, etc.). So in this case, if some software uses the write track command, there is no problem since it will be stored “as is” in the DSK image (no need to “parse” the incoming bytes). If “invalid” data is written in this way, perhaps Cumulus won’t recognize the format if a read sector command is issued afterwards, but that’s kind of expected.