Midwest Scientific 6800, SS-50, PSU help!

[daver2]

That's excellent work. I can already see some slight differences between this and the binary dumps. This does make slightly more sense!

I will update you later...

Dave

 

[fdiskitup]

That's excellent work. I can already see some slight differences between this and the binary dumps. This does make slightly more sense!

I will update you later...

Dave

Im still in contact with the original maker of the system, he confirmed that Flexbug is something that he customized to work with the Electra Super Floppy card, Mwhich he designed. But it was 40 years ago!

I have that card, but I dont know which ss-30 port to put it at. There should be a reference in the code in the KK rom (E800) to a port address somewhere in the region of E004 ?

Meanwhile, I started to look at the motorola 6809 reference manual which includes instruction and a listing for ASSIST09 the motorola debugger. Looking at assembly listings of different “BUG” monitors is beginning to make a little more sense,

 

[daver2]

From the 'new' dump - the duplicated 'M' command at $F6DA is actually an 'O' command.

I have disassembled the 'DISK/MDOS' command (MDOS being an alias for DISK). There are a couple of subroutines that are called that I have yet to disassemble. I am thinking that these subroutines do the actual 'grunt' of the work talking to the disk controller...

Dave

 

[fdiskitup]

From the 'new' dump - the duplicated 'M' command at $F6DA is actually an 'O' command.

I have disassembled the 'DISK/MDOS' command (MDOS being an alias for DISK). There are a couple of subroutines that are called that I have yet to disassemble. I am thinking that these subroutines do the actual 'grunt' of the work talking to the disk controller...

Dave

Dave it's been a while - I finished building my Corsham Technologies 6809 system, taught myself how to work with FLEX09, I wrote my first hello world program in 6809 assembly, used the built in assembler to compile it and then I used the "Dynamite" Disassembler to break it back down into a text file - then I assembled it again from the disassembly text file! and it actualy worked - yes I'm very happy with myself, and this was great fun.

However, the "genuine system" with Flexbug has still not given up all its secrets. I wrote a manual for FLEXBUG.

I fixed both Siemens 8" floppy drive eject mechanisms, they spin, and I can move the heads from a DOS PC with a 34 to 50 pin adapter.

i still cannot get the FLEXBUG pc to talk to the drives, and it may be in the disassembly of the BOOT rom.. ..
basically all the boot needs to do is read the bootloader from the floppy into memory and then run it

 

[daver2]

It takes time to do these things...

Do you want me to disassemble a bit further forwards with the disk bootstraps then?

I am away on a business trip this week, so it would give me something to do in the hotel !

Dave

 

[fdiskitup]

If you can look at the section called "FLEX" at "EAE1" - command should try to get a flex bootstrap.


I found an almost exact match to the command table in the Motorola ASSIST09 command table, so must be based off this monitor (or that's just the standard way to write a command block).
attached is the rom dump as a txt file and the "manual"

 

[fdiskitup]

I have been poking around trying to look for the io ports, "LD A" xx followed by "STA" hhhh - where hhhh must be an ACIA or other io device address , all the addresses seem to be FChh or FFhh.
i may have misunderstood the fundamentals.

to output an ASCii character to the ACIA you would

B6 4D LDA "M"
B7 E0 10 STA hhhh (for ACIA on port 1, E010)
39 RTS

need to read more about direct and indirect etc

 

[daver2]

You can load the X register with the address of the I/O port and then use an offset to index the desired I/O port.

The I/O port itself may also be stored in RAM. So the X register is loaded from a RAM location and then indexed addressing used to access it.

Dave

 

[daver2]

I have done some disassembly around the FLEX entry point at $EAE1.

Most of the code disassembles OK - but there are a few 'very strange' constructs I am coming across that do not make any sense at the moment...

I will give it up for today - and have another look tomorrow (when it is cooler and my brain is not as fried).

Dave

 

[daver2]

Am I being a bit dumb here I ask myself?

The 'R' command displays registers that do not exist on a Motorola MC6800 - but they do on a Motorola MC6809.

Does your machine have a 6800 or a 6809?

Dave

 

[fdiskitup]

its a 6809 (6809P not a 6809E like in the Dragon32/CoCo).

as regards the FLEX entry point and data structures, there must be some data tables for different floppy drive configurations, to deal with SS,SD or DS/DD etc. ?

 

[daver2]

>>> its a 6809.

Ah, that makes slightly more sense now...

The title states 6800, but (looking through the posts) I see I have written 6809 myself as well...

Ok, I will look again with my trusty 6809 tables!

Dave

 

[fdiskitup]

Yes, the original maker really did home brew this.
The case, psu and backplane are all from an msi6800, but its been adapted to 6809 cpu cards.
That means the SS-50 bus address lines are now SS-50c, and the io space is moved from 8000h to E000h (?), I think 16 addresses per port, i.e port 0. = E000 - E00F, port 1= E010 - E01F, etc.
My hope is you can find some reference to a port range for where the floppy controller card should be, randomly swopping card positions has not worked so far…

 

[daver2]

I think I have already found something for the disk controller.

I am working at the moment - so I will dig the information out when I get home...

Dave

 

[daver2]

Being an idiot - I had it in my notebook...

There is (possibly) a subroutine called that writes to memory addresses $FCC0 and $FCC4.

$FCC0 is written with $10 and $FCC4 is written with $D0.

These don't appear to align with your assessment though.

What controller is used on the disk interface?

Dave

 

[fdiskitup]

WD2793

 

[fdiskitup]

SUCCESS ! The 8" Floppy Seeks when I type "FLEX" "DISK" or "MDOS" !!!
However, I don't have a Bootable FLEX disk - the ones I thought I had wont turn in the drive because they are bent and 40 years old . I do have some blank 8" SS/SD soft sector disks... This is going to need me to create a FLEX 9 boot disk from an image with the drive connected to an IBM 34 pin floppy controller. The Super Floppy Controller has 8" and 5.25" support so it may be easier to make a 5.25" and boot from that then build an 8" boot disk.

To make it "work" I took out every chip on the Electra Super Floppy Controller, Cleaned the black pins with a scratch pen, put in Magic deoxit, tested every 74LS chip with the XGECU eprom programmer.
I put deoxit in the 50 pin cable socket.
I put the controller in the slot 0 (previously was in slot 1, as per the manual ...).
----------
As regards the previous discussion of "IO Address space - 8000, E000, etc, I found an article in Kilobaud that describes moving the IO up to address F800 to leave more lower ram/rom free (Peter Stark, 1980, May).
The Midwest Scientific Instruments IO is up in the F500 area, but my board has some bodge wires in the address decoding logic, possibly to give 16 addresses per port and IO in the F800 range.
....

 

[fdiskitup]

I think I found the i/o !

So if I load A with a value (4D=M) from memory 0060h and store A into the ACIA 6850 living at FCF5 - then the ACIA outputs a letter M to the terminal.


I put the code at 2000, and set the program counter P to point at my “program”

Ld A #0060h
STA FCF5
SWI

typing G [return]
Gives me a “M” at the start of the line !

So since the serial card is at port 6 this would allow me to work out the address for the floppy controller in port 0. If I knew number of bytes per port 4,8 or 16 ….

I need this to compile flex 09, so that it knows how to input and output.

 

[daver2]

Well done!

Add that to your documentation...

Dave

 

[daver2]

This is the $FCxx area from your original dump:

       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F   0123456789ABCDEF
FC00  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC10  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC20  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC30  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC40  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC50  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC60  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC70  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................

       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F   0123456789ABCDEF
FC80  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FC90  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FCA0  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FCB0  00 01 00 00 00 00 FF FF  00 01 00 00 00 00 FF FF   ................
FCC0  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FCD0  34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34   ................
FCE0  37 37 37 37 37 37 37 37  34 34 34 34 34 34 34 34   ................
FCF0  00 0D 00 0D 00 0D 00 0D  34 34 34 34 34 34 34 34   ................

I suspect that the I/O page is $FC00 to $FCFF.

Anything containing a value of $34 is 'probably' unused.

Anything not containing a value of $34 is 'probably' used.

$FCF5 contains the value $0D - ASCII <CR> which is not unexpected for the end of the dump command.

I am guessing that the disk controller (assuming it was plugged in when you did this dump) resides at a base address of $FCB0?

It looks like there is quite a bit of 'shadowing' going on?

It looks like two (2) copies of the disk controller registers fitting in the 16 bytes from $FCB0 - $FCBF.

It also looks like four (4) copies of the serial device fitting in the 8 bytes from $FCF0) to $FCF7. What IC is actually on your serial card? Is it a 6850 or 6851 by any chance? In which case the first byte of the pair will be the command and status register and the second byte of the pair will be the transmit and receive buffer - on a WRITE and READ respectively.

Look up the data sheet for your serial device and see if you can get an echo program working...

I am not sure what is at address $FCE0 - but it looks like a single-byte port that is repeated eight (8) times?

Dave