Home Page
Posted By: Xolod Labtam 3000 - 04/17/21 07:03 PM
Gentlemen, I have several PCB, dump ROM, floppy disks and documentation for the LABTAM 3000 computer.
Perhaps there is someone who wants to implement it in MAME !?
https://www.dropbox.com/sh/v9n9l3r5a4ter91/AAB4xdb9URbhueiJAzuQlrJ-a?dl=0
Posted By: R. Belmont Re: Labtam 3000 - 04/17/21 10:54 PM
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?
Posted By: Xolod Re: Labtam 3000 - 04/18/21 05:48 AM
I also have a Nec MFM HDD with some kind of Unix (maybe Xenix or Venix) but the drive fails self test.
Posted By: exidyboy Re: Labtam 3000 - 04/19/21 10:09 PM
Originally Posted by Xolod
Gentlemen, I have several PCB, dump ROM, floppy disks and documentation for the LABTAM 3000 computer.
Perhaps there is someone who wants to implement it in MAME !?
https://www.dropbox.com/sh/v9n9l3r5a4ter91/AAB4xdb9URbhueiJAzuQlrJ-a?dl=0

I seem the BIOS ROM images in your dropbox but not those for any floppies?
Posted By: Xolod Re: Labtam 3000 - 04/20/21 06:18 AM
I made some dumps of 8inch floppy disks. But they can contain personal data of users. They need to be cleaned.
Posted By: Just Desserts Re: Labtam 3000 - 04/20/21 04:57 PM
I'm looking into this.

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.
Posted By: Xolod Re: Labtam 3000 - 04/20/21 06:34 PM
Originally Posted by Just Desserts
I'm looking into this.
I answered you privately.
Posted By: Just Desserts Re: Labtam 3000 - 04/20/21 06:41 PM
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.
Posted By: Just Desserts Re: Labtam 3000 - 04/26/21 11:21 AM
Just FYI, I'm still poking at the driver, I'm just spread a bit thin at the moment. It'll likely go in for MAME 0.232 (the end-of-May release).
Posted By: Xolod Re: Labtam 3000 - 04/26/21 12:06 PM
I can help you?
Posted By: Just Desserts Re: Labtam 3000 - 04/26/21 12:19 PM
Nothing really, the manual is very comprehensive.
Posted By: Just Desserts Re: Labtam 3000 - 04/26/21 07:52 PM
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?
Posted By: Just Desserts Re: Labtam 3000 - 05/09/21 06:54 PM
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
Posted By: R. Belmont Re: Labtam 3000 - 05/09/21 07:06 PM
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.
Posted By: Xolod Re: Labtam 3000 - 05/10/21 08:54 AM
Agree to look strange for initial rom Z80..
[Linked Image from i.ibb.co]
Posted By: Just Desserts Re: Labtam 3000 - 05/10/21 04:16 PM
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:

[Linked Image from i.imgur.com]

The -0 ROM, as you've indicated, also doesn't seem to make too much sense for mapping at address 0.
Posted By: Haze Re: Labtam 3000 - 05/10/21 05:00 PM
try to see if the code functions in the ROMS line up with any of the absolute address jumps / calls you can see.

I suspect neither maps at 0, maybe half size dumps or something

Could also be the upper address line inverted or similar, check the middle of the ROM for the startup code etc.
Posted By: Xolod Re: Labtam 3000 - 05/10/21 05:08 PM
We have another board with z80 installed in a working labtam. I will read ROM dumps from this machine, maybe they will be different.
Posted By: AJR Re: Labtam 3000 - 05/11/21 01:25 AM
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.
Posted By: Robbbert Re: Labtam 3000 - 05/11/21 10:29 AM
The -0 rom comes first, and set the PC to 1800 at start. Then it starts to make sense.

There's no handler for NMI or IM1.
Posted By: Just Desserts Re: Labtam 3000 - 05/11/21 11:52 AM
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.
Posted By: Olivier Galibert Re: Labtam 3000 - 05/11/21 12:36 PM
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.
Posted By: AJR Re: Labtam 3000 - 05/11/21 02:26 PM
There were a few S-100 CPU boards that used TTL to force a JMP instruction onto the data bus to enter boot ROM at some arbitrary address.
Posted By: Just Desserts Re: Labtam 3000 - 05/11/21 02:32 PM
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.
Posted By: Xolod Re: Labtam 3000 - 05/13/21 09:39 AM
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?
Posted By: exidyboy Re: Labtam 3000 - 05/13/21 10:23 AM
Is the NS32000 processor board for the 3000 or another Labtam model?
Posted By: Xolod Re: Labtam 3000 - 05/13/21 11:14 AM
it is from another large rack mount model but the name is unknown.
Posted By: Just Desserts Re: Labtam 3000 - 05/13/21 12:03 PM
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.
Posted By: Xolod Re: Labtam 3000 - 05/14/21 12:11 PM
yes i will dump rom. but I don’t know when. I need a day off for the trip. Just Desserts, do you have any progress on the Labtam driver?
Posted By: Just Desserts Re: Labtam 3000 - 05/14/21 12:49 PM
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.
Posted By: Xolod Re: Labtam 3000 - 05/14/21 02:12 PM
Thank you! enjoy your vacation, we are in no hurry!
Posted By: Just Desserts Re: Labtam 3000 - 05/15/21 02:16 PM
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.
Posted By: Olivier Galibert Re: Labtam 3000 - 05/15/21 05:32 PM
Code
0000: e9 ff 03                       jmp     402h
0402: fa                             cli     
0403: 8c c8                          mov     ax,cs
0405: 8e c0                          mov     es,ax
0407: b8 40 00                       mov     ax,40h

Not sure how you end up at 0x404.. and the byte order does not match, looks like youre interleave is fucked?
Posted By: Just Desserts Re: Labtam 3000 - 05/16/21 09:09 AM
Could be my interleave is fucked, yeah. I'll have a look in a bit.
Posted By: Just Desserts Re: Labtam 3000 - 05/16/21 09:17 AM
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.
Posted By: Xolod Re: Labtam 3000 - 05/16/21 08:32 PM
I added more photo to the folder in the first post. As it turned out, the hdd + fdd controller on Labtam is used the same as that of the Kaypro 10.
https://www.dropbox.com/s/cpywf20re79ckd4/20210514_225850.jpg

https://forums.bannister.org/ubbthr...mp;Board=1&main=8720&type=thread
Posted By: Xolod Re: Labtam 3000 - 06/01/21 10:27 AM
I am repairing mfm hdd, hopefully being able to restore unix from this disk. just wanted to ask if there were any changes to the emulation driver?
Posted By: Just Desserts Re: Labtam 3000 - 06/01/21 11:25 AM
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.
Posted By: Just Desserts Re: Labtam 3000 - 06/13/21 11:07 AM
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.
Posted By: Xolod Re: Labtam 3000 - 06/13/21 11:47 AM
Great news! The boards are not at home, but I will try to get the operatives where they are now. I hope COVID lockdown will not interfere with this.
Posted By: Just Desserts Re: Labtam 3000 - 06/13/21 01:22 PM
Looks like pin 25 (IR7) is hooked up to the MC6845 CRTC's vertical-sync pin.

I've got some video output, but it wasn't quite as exciting as I was hoping:

[Linked Image from i.imgur.com]
Posted By: Xolod Re: Labtam 3000 - 06/16/21 07:40 PM
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?
Posted By: Just Desserts Re: Labtam 3000 - 06/17/21 04:47 AM
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. smile

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?
Posted By: Xolod Re: Labtam 3000 - 06/17/21 08:45 AM
"666" He hints to us about his intentions! =)))

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
Posted By: Just Desserts Re: Labtam 3000 - 06/17/21 10:28 AM
Originally Posted by Xolod
"666" He hints to us about his intentions! =)))

You're not lying... with the vertical sync interrupt hooked up, and the NVRAM checksum test passing, this is all that the system does:

[video:youtube]
[/video]
Posted By: Just Desserts Re: Labtam 3000 - 06/17/21 10:29 AM
So yeah, looks like you're right, I'm going to have to get the Z80 to work.

But I'm still not sure how the system forces the Z80 to boot where Robbbert said that the correct boot code is located...
Posted By: Xolod Re: Labtam 3000 - 06/17/21 10:57 AM
Why do you doubt it?
Posted By: R. Belmont Re: Labtam 3000 - 06/17/21 01:31 PM
Because that's not how the Z80 works.
Posted By: Xolod Re: Labtam 3000 - 06/17/21 03:07 PM
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.
Posted By: R. Belmont Re: Labtam 3000 - 06/17/21 03:09 PM
Ooh, that would be nice! Please do a trace of the first 10 or so Z80 instructions from power-up.
Posted By: Just Desserts Re: Labtam 3000 - 06/18/21 09:00 AM
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.
Posted By: Just Desserts Re: Labtam 3000 - 06/18/21 01:59 PM
I actually have a crazy idea. It's not that the Z80 boots from address 0x1800, it's that it fetches from there.
Posted By: Xolod Re: Labtam 3000 - 06/18/21 08:38 PM
Originally Posted by Just Desserts
I actually have a crazy idea. It's not that the Z80 boots from address 0x1800, it's that it fetches from there.
in this case z80 ice will help. I am preparing a stand.
Posted By: Xolod Re: Labtam 3000 - 06/21/21 10:52 AM
Originally Posted by Just Desserts
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.
[Linked Image from i.ibb.co][Linked Image from i.ibb.co]
Posted By: Just Desserts Re: Labtam 3000 - 06/21/21 11:25 AM
That's excellent info, thanks!

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.
Posted By: Xolod Re: Labtam 3000 - 06/23/21 10:41 AM
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
Posted By: pmackinlay Re: Labtam 3000 - 06/24/21 10:13 AM
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.
Posted By: Xolod Re: Labtam 3000 - 06/24/21 11:11 AM
Originally Posted by pmackinlay
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.
Unfortunately, there is no documentation for this board. There is documentation on boards for i8086 and Z80 which I work with this board.
https://www.dropbox.com/s/qgw4hk47xmv30js/LABTAM%203000%20System%20Manual.zip?dl=0
I will take photos in good resolution a little later, while there is only this photo.
https://www.dropbox.com/s/p81ok1yo6nej4l4/20210622_230741.jpg?dl=0
I can also trace the connection on the board if it is necessary to understand some parts of the circuit.
Posted By: Xolod Re: Labtam 3000 - 06/25/21 10:54 AM
This is how the board looks like with the Z80 ICE.
[Linked Image from i.ibb.co]
Posted By: Xolod Re: Labtam 3000 - 06/25/21 09:22 PM
Found some information on the NS32032 board.
[Linked Image from i.ibb.co][Linked Image from i.ibb.co]
Posted By: Xolod Re: Labtam 3000 - 01/14/22 08:42 AM
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.
Posted By: exidyboy Re: Labtam 3000 - 05/18/22 09:18 PM
Originally Posted by Xolod
I made some dumps of 8inch floppy disks. But they can contain personal data of users. They need to be cleaned.

Are you able to catalogue them ie which operating systems and versions?, languages?, diagnostics? etc have the potential to be preserved?
Posted By: pmackinlay Re: Labtam 3000 - 05/20/22 04:02 AM
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?
Posted By: pmackinlay Re: Labtam 3000 - 05/20/22 04:11 AM
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?
Posted By: Just Desserts Re: Labtam 3000 - 05/20/22 05:30 AM
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.
Posted By: Xolod Re: Labtam 3000 - 05/21/22 01:11 PM
Originally Posted by exidyboy
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?
Unfortunately, I don't have any software for 3232. But maybe these guys have something.
https://arvutimuuseum.ut.ee/index.php?m=eksponaadid&id=223

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)
Posted By: exidyboy Re: Labtam 3000 - 05/21/22 11:24 PM
Originally Posted by Xolod
Here is what we managed to collect from the models:

Thanks so much for all that extra detail. Just to clarify are you saying that you have one of each of these Labtam models?

3000, 3003, 3006 and 3015-V32
Posted By: pmackinlay Re: Labtam 3000 - 05/25/22 03:39 AM
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.
© Forums