• Please review our updated Terms and Rules here

Microkit 8/16

Thanks Dave. I'll check those pins out.. when you say 'boot' are you referring to the load switch?

I wonder if this bootstrap leader is just like my digital group 8080 loader... minus the message to insert tape. I really gotta get a reader put together here. C8702 is identical to c1702 right? Nothing modified between them?
 
Yes. Boot == load.

I have just edited my previous post, so worth re-reading...

Time for bed in the UK so I will catch up with developments tomorrow morning...

Dave
 
Hi Dave,

I actually posted a youtube video showing everything but what happens if the memory boards are removed in a previous post.. hopefully it is easy enough to follow. On power up, there is a screen of random characters, often ? marks. On reset, this changes to a ful screen of 9090s repeating over and over again. Also on reset, the enabled light goes off. Run is always lit no matter what. On hitting load, the screen does not change but the enabled light comes on. Hitting reset again, enabled goes off, screen does not change. I'll pull the ram and see what that does.
 
With all cards out, I get a screen full of question marks. The enabled button still turns off on reset, but there's no action on the screen. I added in the RAM cards one by one, same thing, until I got to the last one - the one with the two jumpers at 4 and 6. As soon as that was installed, we were able to get the 9090 etc screen back again. If that is the only board installed in the machine, same thing.

I tried, just for an experiment, configuring one of the other boards the same way, putting it in by itself, but same thing - 9090s.. no change in behavior.
 
I tried another experiment - removing the bootstrap ROM entirely. The first time I powered up, I got ? marks, and on reset got random stuff being automagically 'typed' onscreen. Second and third time, ? marks, no reset possible.

So then I thought, ah what the heck.. and I borrowed the 1702 from one of my spare digital group 8080 boards. I wasn't expecting anything to happen, but I think it actually *was* trying to run the code... you can sort of make out the '8080 Initialize Cassette' message the dg machine would normally come up with. I'm not sure if the garbling is the differences in video cards, or indicative of a RAM problem.. but yeah.. that's kinda interesting.

Pic here.
 
Question - this Microkit has DIN ports on the back for connecting the tape drives... were these connections for tape recorders standardized way back when? Or am I gonna have to figure out which pin is which and then try to find or wire up a specific cable?
 
Yes, there was a DIN 180 degrees standard for stereo. GND, left and right record and left and right playback.

There should be some way of controlling the cassette motor I should have thought as well. Any signs of any 1/8” jack plugs anywhere?

I have done a bit of ‘digging’ today. I need to look a few things up further tomorrow before I do my next post though.

Dave
 
In one of my photos on google drive there is what looks like an earphone plug. It is attached to the keyboard cable. I thought it was for video.. maybe that is what it is for?
 
Nevermind.. just got a note back from the seller. I had asked them about that plug attached to the keyboard and apparently that *is* for composite video out, not tape. So scratch that.
 
I promised to post all of the interesting things I have found out about this machine. Unfortunately, real work has got in the way... I am back now so here is what I have found out.

The "ENABLED" lamp on the keyboard is (I think) wired to the CPU board INTE (pin 59) which, in turn, is wired to the 8080 CPU (U9) pin 16 (INTE) via a non-inverting buffer (part of U10).

When the CPU interrupts are enabled, this LED should illuminate. When the CPU interrupts are disabled, this LED should be extinguished. On a reset, the CPU interrupts will be automatically disabled (hence the LED will extinguish).

From your video, I suspect the BOOT EPROM enables the CPU interrupts (hence the reason the LED comes on possibly).

This brings us to the RESET side of the system. There are three (3) ways to reset the system:

1. Power on.
2. The keyboard RESET button.
3. The keyboard LOAD button.

I will come back to 1. later...

The keyboard RESET button appears to just reset the 8080 CPU. When the 8080 CPU is reset, the interrupts are automatically disabled and the program counter (PC) is set to $0000. The CPU then starts to execute instructions (effectively from $0000). In your system I suspect this is filled with RAM (not ROM). In this case, I believe, the CPU will just start to execute random 'rubbish' (or whatever the DRAM cards power up with).

The keyboard LOAD button on the other hand appears to set a flip-flop (U25 pin 8 ) which disables all of the DRAM (by setting U3 pin 6 low) and enabling the signal BOOTSEL- on pin 34 of the backplane. I suspect this maps the BOOT EPROM into the 8080s memory map in place of the RAM. I suspect it gets mapped into $00XX, $01XX, $02XX, ... $FEXX and $FFXX (i.e. the entire memory map). The 8080 CPU is reset so it will start executing instructions from $0000 - which is now the BOOT ROM.

Unfortunately, in this scenario, the RAM is disabled - so the BOOT ROM can't write anything into it!

Let us say (for arguments sake) that the BOOT ROM is normally mapped into $FFXX only when BOOTSEL- is inactive.

If the first instruction of the BOOT ROM is a JMP $FF03 this will cause the 8080 CPU to jump from a PC value of $0000 to a PC value of $FF03 and execute the next instruction from there (which is the normal place that the BOOT ROM resides anyhow in my hypothetical case).

I have found out that the U25 flip-flop is reset when the 8080 execute any I/O port READ. If the instruction at $FF03 then peforms an I/O read, the flip-flop will be reset and the RAM will now be mapped in from $0000 upwards, but the BOOT ROM is still present (and being executed) at address $FFXX. The BOOT ROM can now load something from a cassette tape if you had one.

Why go to all this trouble?

If you power up the machine and load the operating system (or an application program) from cassette that takes a long while, the last thing you want to do is to have to reload it every time you hit the RESET button. With this mechanism, the BOOT ROM can load some software into memory starting at $0000 and then, when you hit the RESET key, it will just restart the software you have loaded. This is why I think you have a separate RESET and LOAD button.

Back to the power up scenario. There is a 555 timer IC at U22. From the schematic I sumise that on power-up a LOAD should automatically be performed. If that is not happening, you may have a problem with the power-up circuit. We can have a look at that later.

Next thing, the video card.

You are saying that you get repeating characters of '909090' on the screen. Looking back at the photographs on the original e-bay auction, I see the screen filled with '9@9@9@' characters instead. I couldn't see the graphics on your video (hence why I asked for a better video or photograph).

The video card performs its job via DMA - not by the BOOT ROM transferring data to the screen area. I suspect a piece of RAM (a specific address that we don't know at the moment) should hold the characters to display on the screen.

With your BOOT ROM installed from your other system you may be thinking that what you are seeing has been transferred to the screen. I don't think it has... I think what you are seeing is the BOOT ROM reflected 256 times within the memory map of the 8080 processor and the video card is DMAing from a window onto the screen.

If you look at the screen you will see it is composed of 40 characters by 25 lines. Multiplying these two numbers together gives 960 bytes. If you look at the first few bytes of the screen you will see they are 'C@@R%'. If you count on by 256 bytes you see this repeating. If you count on by a further 256 bytes you will see it repeating again. What I think is happening is that the VDU is DMAing multiple copies automatically onto the screen but not under control of the 8080 CPU. I think the CPU has 'crashed' at this point because it is trying to execute some code that has not been written for this specific machine (i.e. it doesn't obey the rule to perform an I/O read to reset the boot flip-flop etc.).

What else?

It would be useful to get a record of your memory boards - there is a number written on each memory board (#n) and then the links. On the 8080 CPU card the memory appears to be split up into 8K chunks (=1 memory board). U3 on the CPU card decodes the CPUs 64K memory map into 8*8K chunks - driving SEL0- to SEL7- (pins 26 through 33 of the backplane) respectively. My guess is that the links on the memory boards have one side common and the other 8 are wired to pins 26 through 33 to decode for the 8K block. The memory card that has two links fitted MAY respond to two blocks (for a reason unknown at the moment). It may be that the screen memory is 'up high' and using this technique makes one of the memory boards look like two 8K blocks of memory?

The other interesting thing to try maybe is to install the original BOOT ROM and two remove the two data bus buffers (U11 and U12) (8216) from the CPU board. This will mean that the CPU will not be able to read any valid instructions from the BOOT ROM (so it will read $00 or $FF). If I am correct, the original BOOT ROM may now be displayed on the screen! if so, can you photograph it please? We are missing the two highest bits in every byte (the VDU only displays 64 characters) but it may be a chance to hand disassemble the BOOT ROM - and a puzzle over the Christmas period to work out the 512 missing bits! You never know - we could reconstruct the BOOT ROM source code for you and work out what it does :)!

If this is feasible, I wonder if we could modify it to use one of the serial ports to download code from a PC via RS232 instead of the cassette until we work out a way of driving the cassette interface? Just thinking positively...

Dave
 
Last edited:
So I have worked out the order of pins on the edge connector and they seem to correspond (largely) with the list provided in the reference you made to the 8080 CPU card schematic.

The odd-numbered pins (1, 3, 5, ..., 99) are on the component side of the board with the even-numbered pins on the solder side of the board. Pin 99 appears to be marked on the component side.

On the RAM card I can see the upper pins 27, 29, 31 and 33 (/SEL1, /SEL3, /SEL5 and /SEL7) respectively disappearing off to the link block on the RAM cards.

I can only see upper pin 33 (/SEL7) wired up on the ROM/TAPE/EAI and the VDU cards (indicating - possibly - that these cards are mapped into the upper 8K block of memory space).

If you feel like posting high resolution scans/photographs of the front and back of a memory card, the ROM/TAPE/EIA card and the VDU card I may be able to reverse engineer the schematics? I assume they are only two layer PCBs (or is that an invalid assumption on my part)?

Dave
 
Just read a few interesting things in the bitsavers documents...

The DRAM refresh is accomplished by the VDU DMA access every 512 us.

The keyboard strobe (from the CRT card) generates a maskable interrupt.

The BOOT/TAPE/EIA card can generate a 32 us real time clock interrupt.

The BRK (BREAK) key on the keyboard also has a special function. Whether it is operational during a BOOTSTRAP LOAD I don't know.

Dave
 
Last edited:
Fantastic Dave, thank you.

I will get the machine set up here and report back on what I find. That would be really neat if we could 'crash' it and get the BOOT ROM contents.

I will fire up the scanner too and get some high res scans up to my Google Drive.
 
Thanks for the scans and screen image Brad.

I know a bit more now than I did this morning - which is always good :)!

I created a little spreadsheet and entered the first 256 character codes that are displayed on the screen. These correspond to the bytes that (I think) are stored in the BOOTSTRAP EPROM. Unfortunately, the VDU only displays 64 characters, so the top two bits of the bytes contained within the BOOTSTRAP EPROM are missing. My spreadsheet turned the displayed characters into the corresponding byte value (by looking at the character generator data sheet) and displaying the four possible HEX values that it could be for each of the 256 bytes.

I am now slowly disassembling the code, trying to work out the missing 25% of the EPROM bits!

I can't see any text messages within the EPROM, so it is highly likely that you won't see anything on the screen whilst it is trying to boot from your non-existent cassette tapes :-(! I would, however, like to find out where the '9@9@9@' characters come from though. This has to be a function of the BOOTSTRAP ROM - unless this is purely a random power-up effect of the DRAM?

Anyhow, here is what I have got so far. I am working on the first subroutine at the moment...

Code: 
;
; Microkit 8/16 BOOTSTRAP EPROM (1702) 256*8
;

	ORG	$E000	; A guess...
	
E000: C3 03 E0	; JMP E003	- 20, 60, A0, E0
E003: DB xx	; IN xx		- 33, 73, B3, F3
E005: FB        ; EI
E006: 3E xx     ; LD A,xx	- 01, 41, 81, C1
E008: D3 xx     ; OUT xx	- 21, 61, A1, E1
E00A: 3E xx     ; LD A,xx	- 00, 40, 80, C0
E00C: D3 xx     ; OUT xx	- 30, 70, B0, F0
E00E: 31 xx xx  ; LD SP,xxxx	- 20, 60, A0, E0 / 00, 40, 80, C0
E011: 21 xx xx  ; LD HL,xxxx	- 1F, 5F, 9F, DF / 29, 69, A9, E9
E014: 22 xx xx  ; LD (xxxx),HL	- 1F, 5F, 9F, DF / 20, 60, A0, E0
E017: 3E xx     ; LD A,xx	- 07, 47, 87, c7
E019: 32 xx xx  ; LD (xxxx),A	- 1F, 5F, 9F, DF / 22, 62, A2, E2
E01C: CD xx xx  ; CALL xxxx	- 20, 60, A0, E0 / 37, 77, B7, F7
E01F: ??        ; ???		- 00, 40, 80, C0 All 1-byte opcodes.
E020:

Next, looking at the board scans, I think I have found a few interesting things also.

The link block on the memory cards has the numbers 0,1,...7 etched on the board by the links. I think these correspond to the decoded blocks of 8K. I note that block 7 (addresses E000 - FFFF) is missing from the available link configuration on the memory cards. This means that you can only select from blocks 0 to 6 on the memory cards (corresponding to addresses 0000-DFFF).

As you can't select block 7 to be RAM memory (E000-FFFF), and I have seen /SEL7 used on the TAPE/EIA/BOOT card, I suspect that the BOOTSTRAP ROM is mapped into addresses between E000 and E0FF. This (surprisingly) seems to agree with my initial disassembly (and the way I thought the BOOTSTRAP worked initially).

There is a JUMP instruction at E000 to location E003. I suspected that the BOOTSTRAP was initially mapped into the entire memory space, so the CPU would start executing the first instruction from address 0000. This is the JUMP to the correct location in the BOOTSTRAP for subsequent execution.

The next instruction at E003 is an IN instruction. This (I surmised) changed the memory map to re-enable the RAM memory cards.

The next instruction at E005 is an EI instruction to enable the interrupts (and light your ENABLED LED on the keyboard).

You appear to have 5 memory boards. I suspect you will find that each memory board should have a different link fitted and they should be links 0, 1, 2, 3 and 4 - giving you 5*8K = 40K RAM.

The last card has two links fitted - Links 4 and 6. I suspect this means that the last memory card will respond to addresses in either block 4 or block 6 (8000-9FFF and C000-DFFF). My guess would be that block 6 (C000...) is where the VDU card DMAs from to display the image. This is, however, purely a hunch. It does fit with what you have previously found that with this card removed from the system, the VDU displays all '?' - indicating that there is no memory present.

That (I think) is what I have found out today.

Do you have a means of burning your own 1702A EPROMS out of interest?

Now I have started to disassemble the BOOTSTRAP EPROM it does appear to be a nightmare with 25% of the contents missing. We may need to think of a better/easier way of doing this... Do you have access to a logic analyser that we could use?

Dave
 
Last edited:
Just read that each 8K memory board can be write protected in blocks of 1K so that what is loaded from cassette tape - or what is being worked on by the resident editor application - will not be destroyed by running an errant program. There must (therefore) be an 8-bit latch (each bit corresponding to a 1K page of memory) to protect the RAM contents.

Dave
 
Nice work! I regret I don't have a logic analyzer nor a 1702 burner. I have been gathering parts to build one. I have also seen Arduino based readers online but cannot find where they are offered. I'm a bit intimidated by the complexity.

I have been trying to figure out if this prototyping card Marty gave me with digital group stuff is in fact set up to read 1702s... I seem to remember him saying something about that. If we could use my dg 8080 machine to read the 1702 thatd be handy.

I guess there's no way to 'trick's the Microkit into displaying the missing data?
 
You must log in or register to reply here.
Back
Top