Raven. A homemade Atari-like computer

[agranlund]

It works with all of those options.

Nice. Does it run decently on your Milan? Did you get SDL audio?


So for the hang you got I am guessing it detected Soundblaster.
Either falsely or correctly as I have no idea if you actually have such card, nor if it's a PCI or ISA card if you do.
But either way it's obviously quite unhappy with something in the playback codepath.

Is the MFP on Milan not actually mapped to the standard hardware address? If it's not then I understand how it would be quite unhappy as I'm using direct hardware access to MFP and TimerA.

The reason I'm asking is because I saw this in a Milan documentation.
$FFFFC103+4*reg_no | MFP

But it just feels so unlikely to include an MFP but then also break compatibility by putting it at a different address?
Or maybe it maps it to the correct place too in addition to that, or perhaps if that document I looked at is wrong?
As you can tell, I know very little about that machine

Edit: ah it appears to have a range dedicated to ST hardware emulation so I bet it mmu-maps it to the expected place.
Well then, then I don't know and I would start with --no-sbsound if that works.

[peters]

It plays nicely at about the right speed for Tetris.

My Milan has an ISA soundblaster16, there is no sound being produced.

I'm not sure about the MFP, it made me think of serial devices and I found this https://temlib.org/AtariForumWiki/index.php/Milan.

[agranlund]

Now this is borderline pointless but I just couldn't resist...
There's now a "driver" / utility for AIMS Labs FM-Radio ISA cards included in the release package

I have not made any fancy GUI or anything like that,
just a very simple command line utility modelled after how it appears to work in MS-DOS:

[agranlund]

The high speed serial port is now usable by TOS as bios device 7, and it will appear to MiNT as /dev/modem2
One can technically use any control panel but there's a newly built serial.cpx included which is aware of Raven and displays its baud rates correctly.

This is how actual baud rates are mapped to that hardcoded list which some Atari engineer though would be enough for everyone
Ie; If you want to set 921600 baud you use speed index 8 which some things will likely want to display as 600 baud.

Code: Select all

static const unsigned long rs232_bauds[16] =
{
    /*  0: 19200 */      19200, /* same as TOS */
    /*  1:  9600 */       9600, /* same as TOS */
    /*  2:  4800 */       4800, /* same as TOS */
    /*  3:  3600 */       3600, /* same as TOS */
    /*  4:  2400 */       2400, /* same as TOS */
    /*  5:  2000 */    1000000,
    /*  6:  1800 */     750000,
    /*  7:  1200 */     500000,
    /*  8:   600 */     921600,
    /*  9:   300 */     460800,
    /* 10:   200 */     230400,
    /* 11:   150 */     115200, /* same as RSVE */
    /* 12:   134 */      57600, /* same as RSVE */
    /* 13:   110 */      38400, /* same as RSVE */
    /* 14:    75 */      28800,
    /* 15:    50 */      31250  /* midi, because why not? */
};

- Xon/Xoff flow control works and is supported in hardware.
- Cts/Rts flow control does not work yet and I'm starting to suspect a hardware issue. I know this was working on the A0 prototype but I can't remember if I ever tried through the RS232 port proper or if I only connected directly to its debug pinheader.
- Bios buffering and interrupts are not done yet, though it does use the 64byte hardware FIFOs so it's not all bad.

serial_cpx.jpg (17.92 KiB) Viewed 904 times

[Cyprian]

I'm wondering about two things:
- 040 support - Since the 060 price is so high, and there is no guarantee that you will get the full MMU/FPU version, maybe it would be possible to support the 040 as well.
- PCI slots - would it be difficult to add PCI slots as well?

[Oldskool]

Cool.. Just flashed the new ROM

[agranlund]

I'm wondering about two things:
- 040 support - Since the 060 price is so high, and there is no guarantee that you will get the full MMU/FPU version, maybe it would be possible to

Not as easy doing the opposite of putting a 68060 in a board designed for 68040.
Raven only understands native 060 bus, while 060 upgrades for 040 computers makes the cpu start in a more or less backwards compatibility mode.
Saying that, I don't think it would be super tricky to redesign the relevant bits to make it a 68040 motherboard with the possibility of using a 68060 via adapter. It's just not something I'm interested in spending time and money on.

- PCI slots - would it be difficult to add PCI slots as well?

Yes, that would be a very big undertaking. Perhaps more so than the rest of the computer.
And then the accompanying software to make such slot actually meaningful.

I'm half toying with the idea of adding one VLB slot. Easier to work into an existing ISA design and speed was quite good, slightly faster than PCI. But even that, I'm not sure would be worth it (for me). I wouldn't hold my breath.
I'm quite happy using the Raven machine I have at the moment and don't feel much rush in building another revision.

Don't get me wrong I would absolutely not mind faster framebuffer access, but weighted against work + money to iterate a new board and the practical use of faster graphics bandwidth it's not super high up there on my priorities. I'm sure there will be another revision at some point but if that will contain anything in regards to graphics I do not know yet.

It can't deny it would be fun with a 3D card in my machine. Completely pointless in a 100mhz computer of course but would be really fun for tinkering with. But yeah, I'm not seeing myself redesigning the whole thing and adding PCI for that.

I actually think the most sensible thing would be to incorporate Supervidel or a connection for it on the board, gaining standard Atari videomodes too.

[agranlund]

- Cts/Rts flow control does not work yet and I'm starting to suspect a hardware issue.

Cts/Rts flow control is now working and it was a case of PEBCAK rather than a hardware issue

I've only tested with the "SerialDisk" software so far.

Sending speed from Raven->PC seem to end up in the ballpark of what you'd expect for the baud rate but receive is crazy slow when throttled with flow control.
I'm just guessing at the moment but I suspect the usb-rs232 adapter incurs a hefty delay reacting to resume after having been told to stop.
I tried two adapters, each with a different chipset and the FTDI one behaved twice as good as the Prolific(?) in this scenario but it's far from good on either.

The datasheet for the FTDI adapter speaks of a 16ms latency, perhaps that's what is in play here.
I'm hoping a large-ish software buffer and grabbing the hardware fifo from an interrupt might do the trick. Basically reducing the amount of times the adapter is told to halt/resume. That'll be an experiment for some other day.

[Cyprian]

@agranlund I have a question about RAM modules. Will a regular SIMM be ok? If so, which ones are recommended?

[artik-wroc]

I think the answer is "no."

That, and deciding to go with custom RAM Simms, greatly simplified routing on the mainboard
(though routing this thing was still by far what took the longest)
Also, I just think it looks awesome with those custom simms in matching color...

All the Simm slots have exactly the same pinout and each have 16MB physical address space for simplicity.