• Please review our updated Terms and Rules here

Yet another TU-58 emulator

J

jlang

Experienced Member
Joined
Sep 25, 2014
Messages
226
Location
central florida
Everybody has their own take on how to make a TU-58 emulator. Here are my requirements:

stand alone device-no PC needed
greater than 512 blocks
low parts count
solid state storage
passes XXDP CZTUU diagnostics
not wire-wrap or dead bug construction

here it is: https://github.com/joelang/tu-58
 
I just have a few questions:

1) Why not use a 74HCT299 or 74HCT595 part in place of the GAL16V8? The GAL is really not buying you much if at all here, and any builders will need ABEL/GAL programming capability.

2) How do you do block mapping from the TU58 unit ID / block number to the CF card image? In reading the .asm code it appears it is fixed, in that the first 64K blocks are unit 0, the next 64K blocks are unit 1, the next 64K blocks are unit 2, etc, up to unit 255. Am I interpreting your code correctly?

3) Why not just use an Arduino UNO as the base cpu board, and build a nice little shield with the support circuitry? Or maybe your design predated the Arduino project?

Don aka AK6DN aka Mr. https://github.com/AK6DN/tu58em
 
Don
You are correct. the mapping is fixed 64k blocks per unit.
You are also correct the hct595 would be a perfect fit. This is the first pass at this project and I was not certain what the GAL would be called on to do.(first time I did a CF interface)
So I went with a GAL. A second pass board would use the 595

I don't like trying to build an arduino into something. They never look like they fit. Oh... I also have a terminal case of "not invented here" ;-)
This is not intended to slight your TU-58 emulator in any way. I've used it...Works great! I just didn't want to tie up a PC....they always have something else to do.

I'm really glad your looking at the code. My big fear was posting this project and getting nothing but "crickets chirping"

joe
 
Added BOM

Added BOM

I uploaded a BOM to github. looks like about $30 USD.
I'm not interested in selling kits. The entire project is
public domain, so if someone else wants to kit and sell
or sell A+T boards go for it!
 
jlang said:
Don
You are correct. the mapping is fixed 64k blocks per unit.
You are also correct the hct595 would be a perfect fit. This is the first pass at this project and I was not certain what the GAL would be called on to do.(first time I did a CF interface)
So I went with a GAL. A second pass board would use the 595
Click to expand...

Got it. I've never tried more than 4 units on XXDP (or RT11), so I can't say if DD255: (or DD377: octal?) (or DD8: or above) would even be legal, never tried it. I set TU58EM to support 8 units maximum, and noone has ever complained that was not enough. However, the mapping from unit to image is not fixed in TU58EM, so that is a major difference.

I think a '299 would be a direct drop in, whereas with the '595 you have to contend with the output register, so it may not be completely transparent.

I don't like trying to build an arduino into something. They never look like they fit. Oh... I also have a terminal case of "not invented here" ;-)
This is not intended to slight your TU-58 emulator in any way. I've used it...Works great! I just didn't want to tie up a PC....they always have something else to do.

I'm really glad your looking at the code. My big fear was posting this project and getting nothing but "crickets chirping"

joe
Click to expand...

As a young engineer, I had NIH / build it from scratch / rewrite some other code just because I can do it better (or just because) syndrome.

Now as an old fart, the more I can leverage existing projects the better. Time is the most precious variable now over just about anything else.

As to waiting for a response to postings here, it really depends. If you post on a Monday, lots of folks won't read / respond until the next weekend or holiday. Or usually until late at night in their time zone. Only us retired folk read the board during the day :)

Congratulations on getting your code written and reverse engineering the TU58 ROM, that is a significant effort. And passing the DEC diagnostic as well, that is not easy. I have not tried in a while, but last time I did TU58EM would not pass, likely do to the variability of the response time of the PC running the emulator. Having worked to get my RX02 arduino-based emulator to pass the DEC diagnostics I know how much work that can be.

Don
 
Last edited:
jlang said:
I uploaded a BOM to github. looks like about $30 USD.
I'm not interested in selling kits. The entire project is
public domain, so if someone else wants to kit and sell
or sell A+T boards go for it!
Click to expand...

OK! Thanks very much for your response.

I am not able to program a GAL, and I'm not able to program an Atmega chip. If anyone wants to make a kit of parts, please let me know because I'll go for one complete kit, or assembled and tested unit.

Also, I would appreciate seeing some instructions on what needs to be added (CF interface board?), and how to set up the jumpers for what options.

Finally, I would also like to see some instructions for how to program the CF device - can you put the files on from your Mac or PC? Can you only write the files on as if it were a blank tape in a PDP-11 system? Stuff like that.

Thanks...

smp
 
I use "dd" on a mac to load the CF card. You can download images like Don's XXDP stuff (I did that). You can build an image with SIMH (did that) or putr.
You can also "INIT DD0:" But you only get 512 blocks this way.

Don, You've got me thinking about a rev 2 board now... ;-)

joe
 
jlang said:
I use "dd" on a mac to load the CF card. You can download images like Don's XXDP stuff (I did that). You can build an image with SIMH (did that) or putr.
You can also "INIT DD0:" But you only get 512 blocks this way.
Click to expand...

For doing binary image copies to removable media (SDcard, CFcard, SCSI disk on a pc with PCI scsi adapter) I've used 'dd' from within the CYGWIN environment. Works well.

Don, You've got me thinking about a rev 2 board now... ;-)

joe
Click to expand...

On my RX02 adapter shield I went thru two board designs (replacing unobtanium DS8641s with discrete transistor drivers and HCT14 parts) and two or three board revs of each to improve the ease of buildability for novice builders (ie, fixing device footprints, moving parts around slightly, etc. All non-electrical non-functional stuff).

Don
 
jlang said:
I use "dd" on a mac to load the CF card. You can download images like Don's XXDP stuff (I did that). You can build an image with SIMH (did that) or putr.
You can also "INIT DD0:" But you only get 512 blocks this way.

Don, You've got me thinking about a rev 2 board now... ;-)

joe
Click to expand...

Hi Joe,

First I need to say a very nice project. As a big assembler fan I really enjoyed to see a TU-58 implementation in assembler. This is probably going into my new multi-function board for may PDP-11 Hack. Although the board will use a SD-Card and not a CF-Card.

Some thoughts about rev 2. On my RLV12 Hack I'm actually using partitions for volumes. On my MAC I format the SD-Card (CF-Cards will work the same) with many 10Mbyte sized FAT-12 partitions (RL-02) and when I insert the SD-Card the code will scan the partition table, or tables when you have extended partitions. This makes it easier to handle the cards when copying (using DD) images. Also I have built in a function in the RLV12 that rewrites the partition type (from FAT-12 to LINUX) so the next time you insert the SD-Card in the MAC they don't show on the desktop.

I have also built some other projects (not related to PDP-11) where I connected CF-Cards to AVR MCU's. But normally I used a MCU with an external memory interface, e.g. Atmega162, this makes the design extremely simple. I even omitted the address latch and instead of using the latched address I connected some of A8...A15 (Port C) to A0, A1, A2, CS0, CS1 of the CF-Card. And D0..7 are directly connected to Port A. In this way you read and write the CF-Cards register by simply using "lds" and "sts" instructions using addresses with the high byte set to the way you have connected the CF-Card. RD and WR is going to IORD and IOWR. Modern CF-Cards are fast enough that it worked even without any wait states. This would reduce the IC count to one MCU and one RS-232 level converter.

Peter
 
You must log in or register to reply here.
Back
Top