Home Page Forums MAME MAME VME boards

I've been working on hcpu30, and managed to make it boot native Unix into multiuser, but it doesn't run for long. Linux port stops responding after going multiuser.

This Unix needs 1K-sector disks and nscsihd doesn't expect this -- the buffer is 512 bytes long :-)

Heh! I've added support for non-512-byte sectors in various places in MAME, but it was generally because of 256 byte sectors, not 1K :-)

I just pushed an original set of 340x0 tools floppies to http://bitsavers.org/components/ti/TMS340xx/

Thanks, Al.

I've got a Peritek VCU-V/16 board with a TMS34020 (similar to this board).
Unfortunately, it didn't come with firmware EPROMS. Probably robbed by the surplus parts goblins back when I bought it.

Anyway, I've got it loading custom firmware using the toolchain from bitsavers plus a bit of custom ROM-generating code to massage the output of the GSP tools in just the right way. I can single-step through my code up until it accesses the serial port, which is waiting for terminal input. I may put the project on github if anyone is interested.

I did have a question for the MAME experts here apropos terminals on graphics boards. How do I connect to the rs232 port I defined for the SCN2681? Searching shows there's a '-rs232' command, but the current build (or mine) doesn't acknowledge that flag at all. I've scoured the googles and it appears you must build the console into your app, which I did. But that seems to conflict with also having a graphics display. I haven't found an example (yet) that has both a terminal port and graphics. MAME gets confused with having two displays. Yeah, I'm probably doing it wrong.
I was hoping for a way to telnet to the device or somehow use minicom through a virtual terminal device.)

I also have an MVME-167 board. It would be interesting to get some kind of unix running on it with X using this graphics board.

MAME supports multiple (emulated) monitors, so the built-in serial terminal can coexist with your board's graphics display. If you use -numscreens 2 they'll appear in separate windows, otherwise MAME will put them side-by-side in a double-wide window.

For the hookup, you'll need to add an rs232 device, route the necessary signals between it and the UART device, and specify "terminal" for the last parameter. Look at the ht68k.cpp driver for a minimal working terminal hookup to an MC68681 (which for hookup purposes is the same as the SCN2681).

You need to put the -rs232 option after the system name.

Thanks, that was very helpful. I now have a a working text console. Woot!

One unexpected thing when I started was that the terminal window needed to have the baud configured. Yeah, I should have expected full serial emulation for MAME I was able to fix it partly with this:

DEVICE_INPUT_DEFAULTS_START( terminal )
DEVICE_INPUT_DEFAULTS( "RS232_RXBAUD", 0xff, RS232_BAUD_38400)
DEVICE_INPUT_DEFAULTS( "RS232_TXBAUD", 0xff, RS232_BAUD_38400)
DEVICE_INPUT_DEFAULTS( "RS232_DATABITS", 0xff, RS232_DATABITS_8 )
DEVICE_INPUT_DEFAULTS( "RS232_PARITY", 0xff, RS232_PARITY_NONE )
DEVICE_INPUT_DEFAULTS( "RS232_STOPBITS", 0xff, RS232_STOPBITS_1 )
DEVICE_INPUT_DEFAULTS_END

It looks like this worked, but the 2681's Rx seems to be stuck at 9600, so terminal input is garbled. It's possible my 2681 code is only configuring the Tx baud rate, but this works on real hardware at 38.4k. I vaguely recall the real hardware has automatic rate detection. Maybe that's different here. More debugging...

We don't support automatic rate detection, so the baud has to match what the 2681 was programmed for

Yeah, I whipped up a C library for it and had it doing raycasting a while back. Slow!

I tried out a version of the miniforce.cpp and commented out the CPU card and there were no angry fans due to angry scheduler. I'll try it a bit more and I guess I could implement something that just eats some cycles in the case you start without a CPU. I could easily use the HUD to slot in the CPU and then reset the machine and it started as it should.


While fiddling with this I found that the fccpu20.cpp default rom is for a Force 32 system as it is accessing a Force ISCSI board, same as for booting Besta, which wasn't around when the Miniforce was so I am going to add a force32.cpp as a chassi with another set of boards as default and maybe a generic driver/vme.cpp with a number of slots where all the loose VME boards could live until a proper system description is found/implemented for them.

Another thing also occured and that is I need a way to set the default rom from the chassi driver on the CPU board to support the system, eg the focus32.cpp have another rom configured on the fccpu20.cpp compared to miniforce.cpp They both boots PDOS but using different disk controller cards which is hard coded into the roms.