Recent Posts

Pages: 1 ... 8 9 [10]
« Last post by Sunshine Boy on July 17, 2018, 01:32:22 PM »
Download files from

A 40 track bootable disk, it is 16 sectors. 

You need a 40 track drive (360k) on the PC to write the disk.  If you have a 1.2MByte drive you can do it but need to add the -d option and start from a new 5.25 inch 40 track disk - or use a bulk eraser.

You will need SAMDisk, available on the internet
then the commands are like

SAMdisk format -c40 -h2 -s16 -z1 -b1 -g54  b: 

SAMdisk copy newsys.imd b:

CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 12, 2018, 10:48:29 AM »
Yes I think that is what is happening. I spent some time looking at this section of code. As I said I am not familiar with the 6800 (although much more so now). There are a lot of branches to jumps and I assume that this is because the branch address is encoded into the instruction so can only branch over a limited range whereas the JMP can jump to anywhere so branches to 'local' JMP instructions seem to have been used. The instances where one jmp follows another appear to be in blocks of code where a value is being used as part of branch using the nn,X instruction where nn may be one of a fixed number of values. Possibly the people writing the code did not know where the jump was going to go (there seems to be option ROM's missing) and so wanted to test the code for a single ROM. I cannot think of any other reason as the nn,X can of course branch to any address.
Or possibly the lookup tables for the ASCII character set is over 400 bytes so possibly they are using the nn byte value as an index and the X pointer as a selector. I will check the destination addresses at some point to see if this makes any sense.

I would add that this code is very complex and is a series of nested state machines which complete different tasks at the same time in multiple passes.
It incorporates tricks such as using the X register and stack pointer as source destination pointers to move data around in an efficient way.

It is certainly an interesting project but it is starting to look like there is no actual fault and that the ROM to drive the reader was never fitted as the code seems to be looking for a ROM that was never installed when the reader is asked to 'run' rather than read a single character. When it reads a single character it acts as if a keyboard key was pressed or a serial byte was received and this is unrelated to a constant read.
Back then hardware was cheaper than IC's so possibly they always fitted all hardware and only fitted option ROM's when purchased.

Unfortunately this means that my only option may be to try writing code for the missing ROM.

NEW MEMBERS - SIGN IN HERE PLEASE / Re: Introduction . . . to yourselves!
« Last post by DarrenColes on July 12, 2018, 10:26:04 AM »
Greetings Methanoid... Does your handle refer to Deuteros? That is probably my favourite game of all time.
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by DarrenColes on July 12, 2018, 10:23:58 AM »
looks like you are progressing nicely.

Does anyone have any idea why there would be code that has two jumps one after the other to different addresses . The second can never be hit.

The only reason I can imagine you would see this would be if its a jump table accessed using indirect addressing so the disassembler didn't assign a label. I can't imagine why you could do this for only two values though as it would make more sense just to branch to the second one.

I can imagine you might end up with something like this if you were coding the equivalent of

switch (a)
   case 0:
   case 1:
   case 2:

;we enter here with value in A
TAB   ;copy A to B
ABA  ;A = A + B
ABA  ;A = A + B
STA A modify+1    ;self modifying code to update the JMP below
LDX #tablestart

 JMP 1111
 JMP 2222
 JMP 3333
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 09, 2018, 09:09:08 PM »
Further to my last post
If anyone has a ZIP30 with a working tape reader but does not want to let me borrow the ROM or cannot read it then just confirming what ROMs are fitted would still be very helpful.

CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 09, 2018, 09:07:10 PM »
Well, Progress of sorts.
I have completed approx. 30% of reverse engineering the code but unfortunately I do not know the history of this machine.
There are positions on the ROM board for up to 8 ROM's with another on the Keyboard pcb although that one is not mapped into the CPU memory map.
Having found the PIA port that drives and reads data from the reader and the code that sets the PIA configurations I have been able to determine that on a particular port an INT is generated in response to the reader sprocket sensor input and the CPU Interrupt handler checks the two interrupt flags in the PIA that are associated with the reader.
With both flags set it is a single read and with only one flag set it is trying to read the tape continuously.
After locating the point in code where the flags are checked it appears that the code is looking for a ROM that is not fitted.
The code tries to read the first byte of the ROM and if it is not there the value read is FF. The CPU then jumps one way if the number is positive or another way of the number is negative (bit 7 set).
The first byte in each ROM is a NOP (01) so this test seems to be checking if a ROM is fitted and if not it just ignores the task.
The ROM it is looking for should be at address 3400 and this ROM is designated as slot 6 on the board but that ROM is not installed and it does not appear as if it ever was. There is no socket and no sign that a chip has been removed so I am wondering if that option was never fitted even though the reader is in place. Maybe they built the unit with all hardware in place and only fitted the ROM if the customer paid for it.
I will keep investigating but it certainly looks as if that is the case.
Not a good result but at least it gives me some idea of what is going on.
So my options are (assuming I cannot find any other means by which the reader is supposed to work)
1) Find someone with a ZIP30 that can send me the ROM image or lend me the ROM so I can read it (probably labelled '305') [anyone ??]
2) keep reverse engineering the code until I know enough about it to write a new handler for the reader and put it into a new ROM.

NOTE If anyone does have a ZIP30 and wants to try to help please do NOT try to read the ROM in a cheap ROM programmer as they are 2708 and are triple supply ROM's. They are nothing like 2732 devices which can be easily read and programmed.
I have a special (and expensive) adaptor for these devices so I can safely read and program them if anyone is willing to lend me a ROM.

CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 05, 2018, 06:05:44 PM »
Slow progress.
I assume by the analyser output that the 6800 loads the next instruction before it is executed as the next instruction in memory is always hit even if a branch occurs.
Does anyone have any idea why there would be code that has two jumps one after the other to different addresses . The second can never be hit.
Also code such as
ldaa x3300
jmp L3300
This seems to load an address into the accumulator and then have the option to branch there. It does seem to be targeting the start of ROM's that are not fitted so could this be the code checking if option ROM's are present?
The value returned when a ROM is not there is 0xFF so the bmi instruction always branches.

I am hopefully getting to grips with this unit but it is slow because of how it is constructed and the system design.
I am however starting to identify specific subroutines and functions such as the following.

            ;         PRINT HEAD MOVE SUBROUTINE
            ;         RAM 0036 = Head move stepper step count
            ;         RAM 0037 = Head column position
            ;         RAM 0032 = Stepper bit drive value
39E6            L39E6:               ;Not called when paper drives only head move
39E6 : D6 36      " 6"      ldab   X0036         ;Load Head Move stepper step count
39E8 : 96 37      " 7"      ldaa   X0037         ;Load Column position value
39EA : 81 50      " P"      cmpa   #$50      ;Are we at column 80?
39EC : 27 2D      "'-"      beq   L3A1B         ;Yes so do not drive any further
39EE : 5C      "\"      incb                    ;Next Stepper step count value
39EF            L39EF:
39EF : D7 36      " 6"      stab   X0036         ;Save Stepper step count value to RAM 0036
39F1 : C5 02      "  "      bitb   #$02
39F3 : 27 02      "' "      beq   L39F7
39F5 : C8 01      "  "      eorb   #$01
39F7            L39F7:
39F7 : 96 32      " 2"      ldaa   X0032         ;Load current Stepper bit drive value
39F9            L39F9:
39F9 : 84 FC      "  "      anda   #$FC      ;Next stepper phase value
39FB : C4 03      "  "      andb   #$03      ;Strip off unwanted bits
39FD : 1B      " "      aba
39FE : 97 32      " 2"      staa   X0032         ;Save current stepper bit drive value
3A00 : B7 80 0A      "   "      staa   PRINTER_STEPPER_PORT   ;Update Motor drive
3A03 : 96 36      " 6"      ldaa   X0036         ;Load Step count
3A05 : 85 10      "  "      bita   #$10         ;Is bit 4 set (at next column)?
3A07 : 27 12      "' "      beq   L3A1B         ;Exit if not, next pass will step again
3A09 : 84 0F      "  "      anda   #$0F      ;Yes so update column value and stop driving
3A0B : 27 09      "' "      beq   L3A16         ;Check that the lower 4 bits are 0
3A0D : D6 37      " 7"      ldab   X0037         ;Not 0 so Load column value
3A0F : 27 01      "' "      beq   L3A12         ;Not complete yet so set column back
3A11 : 5A      "Z"      decb
3A12            L3A12:
3A12 : D7 37      " 7"      stab   X0037
3A14 : 20 03      "  "      bra   L3A19
3A16            L3A16:
3A16 : 7C 00 37      "| 7"      inc   X0037         ;Increment Column Position
3A19            L3A19:
3A19 : 97 36      " 6"      staa   X0036         ;Store current step count
3A1B            L3A1B:
3A1B : 39      "9"      rts         ;RETURN FROM HEAD MOVE SUBROUTINE

Adding function headers and comments as above and Replacing addresses and naming RAM locations with labels also helps.
Once I have the bulk of the code traced I will hopefully be able to start looking for the fault.

The entire system runs as multiple state machines so untangling it will be fun.

I also had a closer look at the 6801 PIA datasheet and can now see how a port can be an output and an input at the same time (Port A)
That had me puzzled for a long time as I was looking for code that switched the port from input to output but it did not seem to exists and is because It is always an output that can be simultaneously used as an input.

CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 04, 2018, 09:10:24 PM »
Latest update
I have joined all the ROM dumps into a single file and padded each the missing 'ROM' blocks with 1k of nop's
I then ran this through the disassembler using the correct base address and it now gives me a single list file with all the correct address's
Unfortunately the disassembler was not able to properly process the file using threading so I still need to do most of the work from here.
I have replaced all known addresses with Symbols so that the file is becoming more readable and I am adding comments and figuring out what each code block does. I am using the logic analyser to capture specific address ranges so that I can kind of debug the code (observing only of course).
This is not as easy as I had hoped because it looks like it was either complied with a compiler that optimised the code for size or the writer did this manually. It has resulted in a lot of short jumps to avoid far jumps and jumps to 'local' interrupt returns, presumable to avoid multiple pushes and pops where possible as these generate a lot of code.
I am still trying to fully understand the 6821 PIA's as the code performs read, modify, writes and they seem to be able to read a port that is set as and output. I think this must be some kind of internal buffer arrangement in the 6821, I will need to read the spec sheet more carefully.

From the above I have now got as far as realising that the code seems to be arranged as some sort of state machine where a single event is handled in multiple passes so this adds another level of complexity and creates a lot of RAM reads and writes.
I have at least found the part of code where the two modes I mentioned in my last post part ways so I can now follow each to see why one works and the other does not.
NEW MEMBERS - SIGN IN HERE PLEASE / Re: Introduction . . . to yourselves!
« Last post by Methanoid on July 04, 2018, 07:28:20 PM »
I am James and in Hertforshire UK. I found the site from Google when looking for an Eprom service so I can fix some of my old retro up. I'm old enough to have used the stuff 1st time around, ZX81, TRS80, Acorn Atom, Memotech... and MANY more. I often changed my machines! Hello, everyone!
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 03, 2018, 10:28:05 PM »
I will keep you posted, Any comments on my posts would be appreciated.
The device is an old teleprinter terminal with a tape punch and reader attached.
When I got it the entire thing was dead and pretty much scrap but I like to restore old electronics and this seemed like it would be a challenge.
It took me a few weeks to get it working, Nothing worked, Mechanics seized, CPU system dead, Power supply and motor driver board had loads of faults but I finally got it running (mostly).
I am sure you know that these early units were a weird mix of digital CPU and discrete logic with some analog thrown in and some functions are split between firmware and hardware so can be difficult to fault find even with service info and schematic but when flying blind they are much harder.
The fault I am left with is a bit odd.
Everything works except for the tape reader.
It has 3 buttons which I have determined to be Stop, Single character Print and Run (Read and print the entire tape).
The button lights are driven from the CPU and they all illuminate as they should so I know that the CPU can see and respond to the buttons.
However it will only work when the single character key is pressed. It reads and prints the right character but just the one (as it should).
The Run key simply drives the tape to the next sprocket hole and then stops without printing the character. The reader is a little odd if you are familiar with tape readers because it does not have a sprocket to drive the tape. Instead it has a friction drive and two sensors instead of one for the sprocket hole reading. All optical sensors are working.
I think an important point is a fairly subtle one.
If the run key is pressed the tape drives to the next sprocket hole and then stops.
But if the button is pressed again nothing happens, even if stop is pressed first. BUT if the single character key is pressed and then the run key the tape will advance to the next sprocket hole and then stop.
Also if the power is cycled then each time the run key will drive the tape to the next sprocket hole and then stop so it seems that the reader is triggering the firmware as it should but something is failing to complete.
That is why I decided to approach it from the code side as I have no idea how the reader is supposed to run continuously.
It could be a ROM with corrupt code but it would have to be just a few bytes (Cant find binaries anywhere so I cannot check this) or it could be a hardware issue but it would have to be timing or something as all signals from the reader seem to be getting to the PIA and the PIA mode is changing when in run mode.
I am getting into the code and while I have been programming for decades in machine code as well as high level languages it is of course much harder to deconstruct a hybrid device operation and I have also never coded for the 6800.
I have attached a file taken from the logic analyser and I have added some comments on what I think is going on in the CPU from reading the 6800 datasheet. Please let me know if anything is incorrect.
There are two lines for each cycle as I have to capture on both clock edges in state mode or some signals are not properly captured.
Next Step
I have found the PIA interrupt output for the tape sprocket but unfortunately every INT in the system drives the CPU IRQ  so the code will most likely be difficult to decipher as they all jump to the same handler.
The reader can send to a PC via RS232 so it could be something relating to bit timing in the ASYNC chip (Had to replace this) not working or even some odd option somewhere.

Pages: 1 ... 8 9 [10]