Interesting machine! Two 8086s and two Z80s and both the Intel and Zilog parts bins all over the place (plus a 6845 for video and a WD2797 FDC), and the technical manual seems to be OK. I don't have bandwidth right now to look at it, but maybe Duke or crazyc would be interested?
EDIT: Xolod, are there any floppy images that don't contain identifiable user data?
If not, are you willing to share a couple privately so that I can hopefully try to at least get floppy booting up and running enough that you can use the emulated machine to 'clean' the images before a wider release?
I can't read Cyrillic, and I have a hard enough time even reading Australian, so I think your data is in pretty safe hands.
Thanks. I'm a bit tired this evening, I've only had 3.5 hours of sleep, but I'll try to chip away at the driver over the course of the week, and then the weekend. There's a lot of hardware there, so getting everything "just right" might take a short while.
Actually there is one question that I'm a bit unclear on: The manual states pretty clearly that the ROM space for the 8086 board is from 0x70000 to 0x7FFFF, with the upper half of the memory space being reserved for a Multibus window.
Have I overlooked some spot in the manual where it makes it clear how the 8086 is able to fetch its boot vectors, since those invariably come from the upper 16 bytes of the overall address space?
I've started in on writing the driver, hoping that the Z80 would be a more reasonable thing to bring up first.
Annoyingly, there seems to be some strangeness in terms of the Z80 ROMs, right from the beginning.
It's not entirely clear whether "labtam3000-z80-boot-abs-0.bin" or "labtam3000-z80-boot-abs-1.bin" is what's located at address 0 from the Z80's perspective, but I'm betting it's the first one.
That said, the first few addresses it probes are fairly weird.
According to the technical manual, the default would be for memory accesses to default to the "System Map", which has the first 16K for the boot EPROMs, the next 2K at offset 0x4000 for local RAM, then 2K for the "intermap window" (whatever that is) at 0x4800, and then 0x8000 through 0xBFFF mapped to 0xF8000 through 0xFBFFF as an "I/O Buffer Window", mapped to 0xF8000 through 0xFBFFF as Multibus addresses.
These are the first few things the Z80 does. I'm always a bit suspicious when the first thing a CPU does is read things, rather than write things. Does anyone have any suggestions as to what's going on?
Code
[:z80] ':z80' (0003): unmapped program memory read from 8004 & FF
[:z80] ':z80' (0003): unmapped program memory read from 8005 & FF
[:z80] ':z80' (0009): unmapped program memory write to 8014 = 00 & FF
[:z80] ':z80' (0009): unmapped program memory write to 8015 = 00 & FF
[:z80] ':z80' (000E): unmapped program memory write to 8016 = 04 & FF
[:z80] ':z80' (0011): unmapped program memory write to 4030 = 00 & FF
[:z80] ':z80' (0011): unmapped program memory write to 4031 = 00 & FF
[:z80] ':z80' (0013): unmapped program memory write to 0000 = 00 & FF
[:z80] ':z80' (001A): unmapped program memory write to 8004 = 20 & FF
[:z80] ':z80' (001A): unmapped program memory write to 8005 = 01 & FF
[:z80] ':z80' (001D): unmapped program memory write to FFFE = 1D & FF
[:z80] ':z80' (001D): unmapped program memory write to FFFF = 00 & FF
For Z80, check if the IRQ (0x38) and NMI (0x66) default vectors make sense in either of the ROMs. The one where they do will be the correct one at 0 in most cases.
Neither of them make a whole lot of sense as far as initial programs go.
The -1 ROM doesn't seem to have anything valid at 0x38, and the NMI vector is itself a bit weird, though if you shave the byte off of the previous instruction, it produces somewhat sensible instructions:
The -0 ROM, as you've indicated, also doesn't seem to make too much sense for mapping at address 0.
It's not necessarily a given that Z80 code will have an interrupt handler at 0x38, since that's only necessarily the vector in IM 1 (though most arcade games do use that). Anyway, neither of those listings looks much like any sort of boot code to me either.
Interesting, a good question would be how PC ends up becoming 1800. I'm pretty sure it isn't pixies doing it, but the system manual isn't exactly clear on that point.
Maybe look at the 8086 side? The reset vector is very clear there (at fff0) with a far jump to 3000:0000 which is just as clearly where the rom is mapped. It may be that the 8086 boots the z80.
Yeah, the system manual made it sound like the Z80 was the more heavily-used of the boards (for CP/M and the like), so I figured it would be what starts up the machine, but it seems otherwise.
I got the theoretical opportunity to get my hands on a board with an NS32000 processor for Labtam. Unfortunately, there is no software or documentation for it. But perhaps we will find something for her. If there is interest in such a board?
If you can dump all of the ROMs on it, I'm sure some MAME dev can do something with it. As pmackinlay's post in the 2021 WIP thread indicates, MAME now has a reasonbly well-working NS320xx CPU core.
Xolod, it's been an incredibly busy 3 weeks at work. I have a 5-day weekend (today is day 2 of that weekend) to compensate, but I'm looking at some more "fun" things before I get into the grind of a new driver. It'll be either later today or tomorrow that I start piecing it together.
Honestly, if any other dev wants to take a look at this system instead, I would welcome it at this point. This system is baffling the living piss out of me.
The Z80 clearly needs to boot at 0x1800, but the system manual makes it entirely unclear as to how that happens.
The VDU/COMM 8086 boots to 3000:0000, clears interrupts, then executes an "enter 8E8Ch,0C0h" instruction, which puts IP at 0000:0000h in memory that appears otherwise empty.
The "slave" 8086 boots to 4800:0000, clears interrupts, then executes the exact same instruction, with exactly the same results.
At this point I have no idea how this damn thing is even supposed to start up, let alone work.
Yeah, it's a byte interleave, not a word interleave like I have it. Alright, I'll put it back on my queue, but it'll have to wait for later today, as I currently have the CD-i CDIC flayed apart.
Not yet. Hasn't been submitted yet. It's on my list of things to do, ideally once I've wrapped up the Space Panic audio netlist, which should be this week.
I have the VDU board starting to boot. It currently brings up the MC6845, the two Am9513 timers, clears VRAM, initializes NVRAM, and then hangs because it's waiting for an interrupt.
Unless I missed something, the manual doesn't seem to describe which interrupt lines coming out of the Am9513, or any other chips, are connected to the 8 incoming interrupt lines on the NEC D8259 (NEC clone of Intel 8259 Programmable Interrupt Controller).
if you still have the board, Xolod, would it be possible to probe out which pins on which chips are connected to pins 18 through 25 (IR0 through IR7) on the NEC D8259? At this point I can hopefully make some educated guesses by examining code, but it would be easier to just know it.
PCB in my hand, I can search for the desired tracks on the board! I8259 - 18pin connect to mc6845 40pin(vertical sync) 19pin connect to AM9513(U45) 4pin 20,21,22,23,24 connect to 74ls14 25 to ground do you need to track the connections further?
Right, I did make one further discovery this past weekend, which was that my assumption that IR7 was vsync was wrong: IR7 is actually the only interrupt that's always disabled, and IR0 (pin 18, as you observe) is the only one that currently makes the machine move forward. Except all that happens is it fills the screen with the character "6" and glitches out heavily in an infinite loop.
Pins 20-24 being connected to a 74LS14 means those interrupt lines probably need to be inverted due to the chips involved supplying their own interrupts with inverted polarity.
74LS14 is a hex inverter. The output pins are 2,4,6,8,10,12. So some combination of 5 of those pins would be what are connected to 20..24 on the 8259.
The corresponding input pins on the 74LS14 are 1,3,5,9,11,13. Which of the pins on the 74LS14 go to pins 20..24 on the 8259? And what chips feed the corresponding inputs on the 74LS14?
Are you sure that it's pin 4 of U45 that is connected to the I8259 pin 19? Pin 4 on the Am9513 is an input pin, so that doesn't make sense. Are you sure you don't mean pin 37 on the Am9513, which is on the opposite side, but is an output?
I8259 (U19) - 18pin connect to mc6845 40pin(vertical sync) I8259 (U19) - 19pin connect to AM9513(U45) 4pin and connect over two serial Schmitt trigger (74ls14 - U59) to external connetor J2-30pin I8259 (U19) - 20pin connect over one Schmitt trigger (74ls14 - U58) to D7201C(U35)-28pin = Serial port 1 INT I8259 (U19) - 21pin connect to 74F02(U17) 10pin. U17- 8,9pin connect to RN1 (4k7 to +5V) and D7201C(U27)-28pin = Serial port 2 INT I8259 (U19) - 22pin connect over two serial Schmitt trigger (74ls14 - U59) to external connetor J2-17pin I8259 (U19) - 23pin connect over two serial Schmitt trigger (74ls14 - U58) to external connetor J2-11pin I8259 (U19) - 24pin connect over one serial Schmitt trigger (74ls14 - U58) to external connetor J2-13pin BUT CUTED and connect to 40PIN (INT3) MULTIBUS SLOT Connector I8259 (U19) - 25 to ground
if there are any ideas, then I can look at the board for what is connected. Also i can try put on the board of ICE Z80 https://github.com/hoglet67/AtomBusMon , I have it! And dumped all activity Z80.
By the way, the reason for the 8086 VDU card freaking out is because of my flawed initial implementation: I had ROM mapped at both F0000 and 30000 so that the boot vector could be fetched.
I've switched to using a read tap which unmaps F0000-FFFFF as soon as the boot vector is fetched, and the VDU card now appears to be functioning more or less normally.
When the first vsync interrupt comes in, the VDU card looks at F8000 (which is located in the half-meg upper window into the Multibus address space). If it's zero, it simply sits in a tight loop, reading the location.
Since I had the boot ROM mapped in that range, it was seeing a non-zero value, then completely freaking out due to what would apparently be invalid data in that range.
So yes, at this point I suspect what's needed to move forward is to get the Z80 up and running.
I actually have a crazy idea. It's not that the Z80 boots from address 0x1800, it's that it fetches from there.
So the Z80 ICE is connected, the processor is running at a clock frequency of 5 MHz. I confirm the Z80 from the zero address is the code that is in the ROM with # 1800 address. until # 0800 in and then repeating this page of memory at all addresses # 0800, # 1000, # 1800, # 2000, # 2800, # 3000 and up to # F800.
I'm currently at work for the next 2 hours or so, but I'll get back to you after that for more information about the ICE commands. Mainly, I want to see if I can manually invoke IN opcodes in order to see what the mapping RAM defaults to on reset.
I got a great LABTAM V32 system! It consists of a main processor board on CPU - NS32032, MMU - NS32082, FPU - NS32081, 2 Megabyte RAM. Additional one or two RAM board with 6 Megabyte. Four board with CPU - 8086, MC6845, 4 terminal port (The board is the same that we are currently implementing in MAME) Controller SMD HDD - INTERPHASE SMD 2190 Controller 1/2 inch TAPE with PERTEC interface - Xylogics 472 I also dumped the BIOS from the NS32032 board. It looks like there is also support for Booting from the Z80 board (FDD + MFM HDD). https://www.dropbox.com/s/p81ok1yo6nej4l4/20210622_230741.jpg?dl=0
That's interesting! Do you have any pictures of the boards and/or documentation? Those three ns32k family chips are all emulated pretty well in MAME now, so adding this system should be doable.
That's interesting! Do you have any pictures of the boards and/or documentation? Those three ns32k family chips are all emulated pretty well in MAME now, so adding this system should be doable.
Gentlemen, maybe in the new year who wants to continue working on LABTAM emulation? If there is interest in this, then I can try to draw a circuit on PCB.
Xolod, we now have a slightly more functional Multibus emulation in MAME, which should give a good base to get this system working. Can you please share some information about the system configuration with the 3232 card installed? Does the 3232 board fit in the same card cage that was used for the Z80 and 8086 boards? Does it work standalone, or does it require the Z80 and/or 8086 cards installed to make a working system? The datasheet indicated it has a SCSI device, but I don't see one on the board picture - does your system have anything connected to those ribbon cable connectors on the top edge of the 3232 board and/or can you verify if either or both of them are SCSI?
Is your unit the "desk top unit" mentioned in the manual, or some other configuration? Which slot is the 3232 board installed in?
Do you have any NS32000 software for the 3232 board aside from the firmware?
Also the photograph of the board you provided isn't ideal - there are a number of devices where it's very difficult to read the part number. Can you possibly provide additional images with better quality?
By the way, Patrick, if you want to take on the base system itself, you're more than welcome. I just don't have the bandwidth or inclination to debug it at this point.
Are you able to catalogue them ie which operating systems and versions?, languages?, diagnostics? etc have the potential to be preserved?
Now there is Concurrent DOS v4.1. Other software needs to be dump from a large number of 8 inch floppy disks.
Originally Posted by pmackinlay
Does the 3232 board fit in the same card cage that was used for the Z80 and 8086 boards?
Yes, same boards. And in V32 machine with four 8086 board for work 16 terminals.
Originally Posted by pmackinlay
Does it work standalone, or does it require the Z80 and/or 8086 cards installed to make a working system?
Z80 and 8086 required for V32. (terminals, video, keyboard, FDD)
Originally Posted by pmackinlay
The datasheet indicated it has a SCSI device, but I don't see one on the board picture - does your system have anything connected to those ribbon cable connectors on the top edge of the 3232 board and/or can you verify if either or both of them are SCSI?
Yes, the SCSI controller was an option, and it does not soldered into my 3232 board. The photo of the board shows unsoldered microcircuits and a SCSI connector. I assume that it was an NCR 5380. Two connectors on the top of the board connect RAM expansion boards.
Originally Posted by pmackinlay
Is your unit the "desk top unit" mentioned in the manual, or some other configuration? Which slot is the 3232 board installed in?
Do you have any NS32000 software for the 3232 board aside from the firmware?
I will take good photos of the boards in the near future. To run this machine, you need to start with the implementation of the Z80 board, then the 8086 board, and then the 3232 board. It shouldn't be very difficult as there is a System Manual with a description of the system architecture. It is also possible to debug the Z80 board using the In Circuit Emulation device. And if necessary, restore part of the circuit on the PCB. I will be glad if you @pmackinlay try it.
Here is what we managed to collect from the models: 3000 1983 ???
3003 1983 Desktop Board: one - Z80 SBC one - 8086 VDU/COMM one - WD1002-HDO (Like Kaypro-10) https://retrocmp.de/kaypro/kay-p2_hrdw.htm#hdc one - FDD 5'25 - Connect to WD1002 board one - MFM HDD 5'25 NEC D5124 10MB - Connect to WD1002 board
3006 1983 Monoblock Board: one - Z80 SBC one - 8086 VDU/COMM two - FDD 8" - Connect to Z80 SBC board (to WD2793A on board) one - FDD 5"25 - Connect to Z80 SBC board (to WD2793A on board)
3015-V32 1985 Tower Board: one - Z80 SBC four - 8086 VDU/COMM (one board with main ROM and others slave ROM) one - V32 (main processor board on CPU - NS32032, MMU - NS32082, FPU - NS32081, 2 Megabyte RAM), Optional SCSI contoler on board. one or two - Additional one or two RAM board with 6 Megabyte. one - INTERPHASE SMD 2190 (Controller SMD HDD) one - Xylogics 472 (Controller 1/2 inch TAPE with PERTEC interface)
I've done some work on the Z80 SBC and believe I've found a plausible explanation for the 0x1800 firmware offset. According to the manual, all Z80 memory accesses pass through the address mapping logic, which maps logical to virtual addresses with a 2K page size granularity. The mapping logic supports 8 maps of 32 pages, and generates address bits 19..11 as well as RESB (resident bus vs Multibus access), MEM/IO and WP (write protect) signals. My theory is that during reset (and probably during interrupts) the mapping hardware is disabled, and its outputs are forced or float high. This has the effect that Z80 memory accesses during these cycles have address bits 15..11 driven high, and the other signals indicate resident bus, memory, read-only accesses (i.e. on-board EPROM). When combined with the initial mapping established by the firmware indicating EPROM #0 is decoded at 0xe000 on the resident bus, the result is the Z80 fetching logical address 0 from physical 0xf800, which is offset 0x1800 in the firmware.
Based on an initial implementation, it's now trying to access the floppy disk drive, so that's promising.
With lots of help from Xolod, I have the Z80 and 8086 boards up and starting to talk to each other.
This is the current result of starting up with the CP/M-86 floppy in the drive, but the system doesn't do anything else after this - maybe it's waiting for a keyboard.
![[Linked Image from i.ibb.co]](https://i.ibb.co/7vxPW02/z80-disasm.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/tD7Pderl.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/9Vqf2YA.png)
![[Linked Image from i.ibb.co]](https://i.ibb.co/XLzRqKM/z80-ice1.png)
![[Linked Image from i.ibb.co]](https://i.ibb.co/pnt9QGY/z80-ice3.png)
![[Linked Image from i.ibb.co]](https://i.ibb.co/1MwD9zP/20210621-141704.jpg)
![[Linked Image from i.ibb.co]](https://i.ibb.co/tJvgXSf/20210625-215210mini.jpg)
![[Linked Image from i.ibb.co]](https://i.ibb.co/GP5sDQW/20210625-215157min.jpg)
![[Linked Image from i.imgur.com]](https://i.imgur.com/TdRMkAx.png)
![[Linked Image from i.ibb.co]](https://i.ibb.co/2dz68Cp/IMG-20220924-WA0001.jpg)
![[Linked Image from i.ibb.co]](https://i.ibb.co/WfqY202/IMG-20220928-WA0000.jpg)
![[Linked Image from i.ibb.co]](https://i.ibb.co/DpjxnXh/IMG-20221211-WA0001.jpg)