Cumulus Booted First Game
Posted by retromaster on November 24, 2010
-
- L’Aigle D’Or Loaded with Cumulus
-
- Cumulus Direct Connection
I checked the Oric Bus lines with the oscilloscope and it seemed that there could be some signal integrity problems (overshoot, excessive oscillation, maybe even crosstalk). So I decided to remove the ribbon cable in between Cumulus and the Oric and connect Cumulus directly to the Oric by means of a makeshift male-male adapter.
The result was a huge improvement. Now I am able to boot Oric DOS disks without problems. Sedoric 1 disks also work (like the above L’Aigle d’Or). Unfortunately, Sedoric 3 still does not boot. It sometimes crashes with garbage on the screen, or other times, I get the Sedoric copyright boot text but also a warning that says “DOS is altered”, and it is stuck there. A commented disassembly of Sedoric 3 would have been very helpful at this stage… Anyway, it looks like I am getting quite close :).
Getting Sedoric 3 to boot is the first priority now. Once I get that to work, I might work on a new PCB design that gets rid of the separate UI daughterboard and puts everything on one compact, integrated board. To be able to do that, I’ll need to figure out if the cable can be left in place (solving the signal integrity issues in some other way), as that has a direct bearing on the mechanical properties of the board.
Retromaster's Electronics Projects 
Gokhan said
Harika gidiyorsun 🙂 Bu projeler hayata geçmeli…
retromaster said
Teşekkürler, Gökhan. 🙂
kamelito said
Hi,
Sedoric 3 info in french
Click to access sedna3_0.pdf
Read this thread also, you might have the same problem: (last quote posted below)
Kamel
Well, I finally nailed the sedoric bug.
I loaded up Euphoric on my PC and Oriculator on my Amiga, and traced the boot sequence of toxic_slime.dsk side by side, looking for where Oriculator differed to Euphoric. This was an incredibly tedious, painstaking task that took several hours. But I finally found the problem.
It seems I already had the answer right in front of my eyes. Here is a quote from an earlier post in this very thread:
Quote:
It seems to me that it only works after a reset because before jumping into the sea of BRKs, it sets up the interrupt vector to point to $d0a5. Then, when you reset Oriculator, that vector changes the checksum calculated in step 8 to be non-zero, so on the second time through, steps 11, 12 & 13 are executed, and X contains $3C instead of $04, and a lot more sectors are therefore read from the disk.
… If there is anything at all in overlay RAM, SEDORIC reads $3C sectors instead of $04.
From my painstaking trace work, I found that, at the point where SEDORIC checksums overlay ram, NOTHING AT ALL HAS BEEN WRITTEN TO IT. It is checksumming nothing in particular. Or, worse…
When cold booting, Oriculator sets all ram to zero, but Euphoric fills it with a specific pattern.
This pattern is essentially meaningless garbage that all real orics happen to have when you turn them on (well, actually there are two possible garbage patterns, but they’re both garbage). This means that overlay RAM has meaningless garbage in it. SEDORIC checksums meaningless garbage to determine how to boot.
I can now answer my earlier questions:
Quote:
1. What is *supposed* to be @ $c980 to be checksummed?
Any old crap. Just not all zeros.
Quote:
2. Why isn’t it there?
Because neither microdisc ROM or SEDORIC actually put anything there.
Quote:
3. Why does anything at all being in overlay RAM make it read $3C sectors instead of $04?
Because SEDORIC is retarded.
So anyway, I’ve now put the default memory patterns into oriculator, and sedoric now works.
original thread : http://forum.defence-force.org/viewtopic.php?t=458&postdays=0&postorder=asc&highlight=random&start=60
retromaster said
Thank you very much for the info.
Anyway, I think “the problem” may actually not be more than a dumb mistake on my part. I only found out this morning that the Sedoric 3 disk images I was using for the tests are actually “slave” disks. So, probably it was already working to begin with… I’ll test this evening and probably follow up with a new blog post tomorrow.
-RM
Dbug said
About your cable/bus problem, the issue was already known by people doing extensions for the Oric back in the time: There was a device called AmpliBus which was specifically designed to fix this kind of issues.
I know that some people of the CEO (Club Europe Oric) are right now working on a project that required that to work well, so they made a new Amplibus board with built it address decoder.
retromaster said
Thanks for the information, Dbug.
After your comment, I did check the original AmpliBus circuitry (scans provided on the net by Andre Majorel) and it seems that it’s nothing more than a few simple 74LS244 buffers on the bus. I think that the ideal setup here would be to put the buffer circuitry (i.e. AmpliBus) right at the Oric expansion slot, and optionally, use sufficient termination (probably just passive circuitry would be enough) on the Cumulus side to make sure that the bus operates properly.
That said, as long as Cumulus works properly when directly attached to the expansion port, there is no need to be concerned with all this stuff. The only problem I can see here is that, since I originally designed Cumulus to be used with a cable, the PCB is a bit wider than the expansion port, and that slightly obstructs the neighboring connectors. The new PCB design will need to be slightly narrower to prevent this.
-RM