Raven. A homemade Atari-like computer

[dml]

Thanks - that's very helpful.

So the impacts would be:

1) modding my board: would be visible as a bodge on the topside of the board but unlikely to cause other/future problems.
2) changing the 1508 pin mapping: least disruptive but I would need to patch & rebuild the FW if there are any updates to that
3) changing the bootloader: potentially beneficial for others but complicates the bootloader and could be a PMMU debugging rabbithole \o/

I think that's enough info for me to decide what to do here. One obvious wrinkle is that I would need to decide before soldering simm socket 0 to the board - and testing default FW can't be done without simm socket 0. That adds to the fun slightly but suggests the 1508 direction would be the first direction to try, if anything.


Slightly offtopic, but presumably the bootloader - which is setting up the pagetables - is also setting the cache behaviour as writethrough-vs-copyback? Or would changes there imply changes to signalling and 1508 logic also?

[agranlund]

2) changing the 1508 pin mapping: least disruptive but I would need to patch & rebuild the FW if there are any updates to that

I can't imagine it would disrupt anyone if I made the default firmware have the ram slots reversed, so I'd vote we go with that?
At most you'd need to swap around some simms if slot3 wasn't populated before.

I do like option 3 for the sake of polish and completeness, it would be nice if it just works regardless of what slots you use.
There is an alternative motive here in that I've been wanting to find time to make a combined rom/ram simm. Mainly so that you can run the machine with just that one simm in slot4. Or if you wanted to have an additional (16-romsize) MB of ram.

Slightly offtopic, but presumably the bootloader - which is setting up the pagetables - is also setting the cache behaviour as writethrough-vs-copyback? Or would changes there imply changes to signalling and 1508 logic also?

Yep, that's all on the software side in the bootloader and won't effect anything on the hardware or firmware side.

[sety]

Slot 0 is both mandatory and very close to the CPU. Anything added in the CPU area which takes up extra space would interfere with the mandatory slot first.

I wanted to do a similar thing, since modern cases have a big glass panel on them, I really want to show off the hardware, so I wanted to use 22deg sockets so all the chips are visible, but It collides with the CPU.

I can't imagine it would disrupt anyone if I made the default firmware have the ram slots reversed, so I'd vote we go with that?

I'm all for it! I was going to offer to test it for dml on my rig, but I can't get WinCUPL to work under Windows 11. :lol:

[PhilC]

Changing the ram slot order in the 1508 code sounds like the easiest option to me.

I had also been wondering about the possibility of adding more ram, not that I've needed to do so, so the ram/rom one does sound interesting too.

[dml]

I can't imagine it would disrupt anyone if I made the default firmware have the ram slots reversed, so I'd vote we go with that?
At most you'd need to swap around some simms if slot3 wasn't populated before.

That does seem like a nice short-term solution!

I do like option 3 for the sake of polish and completeness, it would be nice if it just works regardless of what slots you use.

It would be nice yes, if a bit more work on the software side.

There is an alternative motive here in that I've been wanting to find time to make a combined rom/ram simm. Mainly so that you can run the machine with just that one simm in slot4. Or if you wanted to have an additional (16-romsize) MB of ram.

:coffee: ....interesting!

Yep, that's all on the software side in the bootloader and won't effect anything on the hardware or firmware side.

That's good to know. I made a cookie API to control caching modes by address ranges from user space on AB40 so I might look at something like that on Raven eventually - but probably will get distracted with ISA cards long before that :)

[agranlund]

That's good to know. I made a cookie API to control caching modes by address ranges from user space on AB40 so I might look at something like that on Raven eventually - but probably will get distracted with ISA cards long before that :)

That sounds quite nice and better than what is there right now :)

The only controls I have implemented sets the cache behaviour of the entire range of ST and TT ram respectively.
Stored in nvram and can be set from the boot monitor:

Code: Select all

cfg st_ram_cache <x>
cfg tt_ram_cache <x>

(or more easily though the GUI of rvbios.prg)

The bootloader exposes some functions which can be called by anyone. It includes some mmu helpers which could come in handy for what you suggested, or you could do it all manually too of course.

"sw/lib/raven.h" shows the currently exposed interface.
"sw/rom/mon/export.c" is where it's being setup.
Feel free to change and/or add anything to wherever - I don't hold much of anything sacred, it's all very much work in progress and perhaps messy in places.

[agranlund]

I'm all for it! I was going to offer to test it for dml on my rig, but I can't get WinCUPL to work under Windows 11. :lol:

Haha, yeah I had to set up Windows XP in a virtual machine for it :lol:

[agranlund]

On the subject of reversing orders of things.

I am very heavily leaning on changing the IDE slot to Motorola byte order on Raven.A2, to make it identical to normal Ataris.
EmuTOS will work with either, so from that perspective there shouldn't be a compatibility issue, but there are pros and cons to both.

Intel byte order:
+ Drives partitioned on PC are faster (no software byteswap)
- Drives partitioned on Atari are slower (software byteswap)
- Cannot use Atari partitioning software or drivers (HD-Driver etc)

Going with Motorola byte ordering pretty much reverses the above.
I went with an Intel interface as I figured the most common case is to prepare the CF card on a PC so optimised for that but in the long run it feels like it wasn't the best choice sacrificing Atari compatibility for this.

I'm going to do some test on Raven.A1 + a plugin byteswap adapter but it would be interesting to hear inputs on this subject :)


Having a stock Atari style IDE interface would also make getting MagiC up and running a fair bit easier - right now it's at the point where it needs to execute a driver from the IDE bootsector to get further - of which there are none that understands the Intel wiring (unless perhaps pperas driver do -- I'll need to give them a test).
Same if someone wanted to get Atari TOS3 running on Raven for some reason. That in itself shouldn't be _that_ difficult except for the lack of IDE drivers that can understand Intel style interfaces.

If it's just me favouring an Atari style interface then I'll keep it as-is and use the adapter which I will make anyway for my current board.

[PhilC]

@agranlund it did take me a little while to work out how to get everything set up and working properly. I made 8 512mb partitions on a 4gb SD card. I'm happy with it as it is as it's easy to put the card into my Mac and transfer files over, although the . spotlight files are a nuisance that I need to work out how to stop the Mac doing.

However, if we still had a compatible swap partition, it wouldn't really matter if it was intel or Motorola byte order.

Do we have a need to swap HDD drives over often between ST and the Raven I wonder.

[agranlund]

That's enough KiCad for a while now..

Made and ordered an IDE byteswap adapter so I can continue in getting MagiC running on Raven.

byteswap.jpg

Stopped procrastinating about it and moved a bunch of stuff around to make space for CKBD, Ethernet stuff, and a USB hub.
(I figure it can't hurt to have an additional two USB ports on an internal header)

I'm not the biggest fan of routing so it always hurts when ripping up tracks :lol:

a2mess.jpg