Not able to read Orton ROM

[James Harland]

Hello everyone,

I put the Orton 3C ROM board together today, but was unable to read the routine I wanted from it. In the end I simply wrote a little routine to see what was at address $4000, but I got FF back rather than the hoped for C3.

I have put the inhibiting jumper on the RAM board, and have set the jumpers up on the ROM as shown on the pictures here. I'm hoping it's just a case of me having the jumpers wrong and not something more serious.

Thanks for your advice

James

[James Harland]

I tried setting the jumpers on the ROM to 000, and this time got something more plausible back from $4000 (3A, so LD A), but not what is listed on the Codeberg listing - should be C3.

[James Harland]

With the ROM jumpers on 000, I consistently get 3A back as the contents of $4000, which seems that I am really reading some data there. This happens after resetting power, and several runs. So maybe there is something different to the ROM listing here on my ROM, at least at this position?

[James Harland]

Using LDIR I inspected a few more addresses from $4000 onwards, and got the following. It didn't seem to make any sense when I first saw it, and disassembling this seemed to prove this. In any case it is not what is listed at Codeberg. 

Again, this is when the ROM jumpers are set to 000

4000 3A LD, A ($3031)
4001 31
4002 30
4003 34 INC (HL)
4004 30 JR NZ, 30
4005 30
4006 30 JR NZ,30
4007 30
4008 30 JR NZ, 43
4009 43
400A 33 INC SP
400B 30 JR NZ, 33
400C 33
400D 34 INC (HL)
400E 33 INC SP
400F 43 LD BE, E
4010 33 INC SP

[James Harland]

Having carefully re-read what there is to read about the ROM module, it seems that A14 should be held high for anything to happen. Maybe I am just reading RAM with the above?

So are the correct initial settings (as per the pictures):

A14 1

A15 0

A16 0

with the jumper on the CPU/RAM board also installed?

I did wonder if the 74HCT02 chip was properly seated, so I popped it out, straightened up the legs and reseated it yesterday, but that was still with A14 at 0.

[Alan Cox]

Odd that no byte has the top bit set. Does that continue to be the case in the ROM area ?

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/38e553b5-cf84-41bb-ad94-ff1f013a409en%40googlegroups.com.

[James Harland]

That's true, though if I add in the top bits where needed, I still don't get to the code I expect to see.

I'm not sure I follow your question. My understanding is that the ROM ought to be visible from $4000 to $7FFF, so in order to inspect it, I used LDIR to copy it down to somewhere more accessible in RAM, and the results are above. 

In RAM I am able to set any bits I like, and have successfully run some little routines.

[Alan Cox]

Does 7FFF have the high but set on the data - that will tell you in many cases if there is a solder short on the ROM board between D7 and an address except A15. If there are bad connections on D7 somewhere it may not but you can visually inspect.

Don't, from experience, assume there is one fault. Work through each odd thing independently. It will often lead to a single cause but not always. Instead as you fix one the others become clearer.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/3ff837cf-4731-4287-a786-fe910e136e0dn%40googlegroups.com.

[James Harland]

Thanks, though I'm not sure I've got things set up properly in the first place. I don't really understand the function of the jumpers on the ROM board. I have gone back to having only the A14 jumper set, and can confirm that I can only read FF from the ROM in that case (having run LDIR with different parameters). 

[James Harland]

OK, where I've got to with trial and error and various machine code routines:

1) If jumpers on ROM board are set to 000, I can access some kind of ROM

- it always reads the same starting at $4000, including after power off (3A, 31, 30 = as above).

- I cannot write to it - if I try to write to $4000 and then read it, I get 3A back

- This is not what I expect to find there in terms of the Orton 3C ROM code, and as Alan said it is curious that the high bit is never set

2) If the jumpers are set to 100, 110 or 111 I just get FF back. I suppose this will be the same with the other positions.

3) I'm pretty proud of myslef that I've been able to write Z80 code to do this troubleshooting :-D, and happy that the basic Orton 3C unit seems to be functioning correctly

Things I have tried to do to troubleshoot/fix things:

1) examined carefully my solder joints on the ROM board, and reflowed a few joints

2) reseated both the NOR gate chip and the ROM itself (the latter in the green thingy) - I do wonder if I damaged the NOR chip either initially or when I reseated it. At some point one of the legs was very bent, but I did manage to straighten it out. I also wonder if I damaged it with static when I was manhandling it trying to get it in the first time.

3) made sure the jumper on the RAM/CPU board was seated properly

4) superstitiously tried different slots on the backboard in case that makes a difference :-D

5) following Alan's advice checked the high bit on $7FFF - it is indeed set, indeed the value that comes back from there is FF

I'd be very grateful for any advice on next steps. This is only my second retro computer build, the first being the RC2014 Classic ][. I don't have an oscillator, but am willing to accept if now might be the time to buy one :-D

[Spencer]

Hi James,

Something odd is going on there, but I am not sure exactly what.  Have you got the high byte / low byte order correct in your LDIR?  However, just to clarify;

• The RAM Disable jumper on the CPU/RAM Module does need to be set.
• The A14 jumper on the ROM Module does need to be set to 1 and the A15 A16 jumpers need to be set to 0
• The code on your ROM chip should be the same as the Codeberg listing.

The ROM is 128k, but the 3 jumpers on that module connect to the ROM address lines A14-A16 and divide it up in to 8 16k banks.  The other address lines (A0-A13) are driven by the Z80 and tell the ROM which byte of data to return.

Because the ROM starts with an offset at 0x4000 I decided to simplify / cheat (depending on your point of view) when compiling the code and burning it to ROM.  This means that the first 16k bank of ROM is ignored completely, which is why jumper A14 needs to be set. (If you are burning your own ROMs then of course you can put your code on whichever banks you want and address it with the jumpers accordingly).

Have you tried just toggling in a jump instruction and running the code in ROM? C3 14 40 should run the code that will set all the RAM to 00

Spencer

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/406ead6e-0661-4da8-a631-2098863f26b6n%40googlegroups.com.

[James Harland]

Thanks for your reply, Spencer!

I set the A14 jumper, and tried to run C3 14 40 76, but the program did not reach halt, and the RAM was not set to 00.

I'm pretty sure I've been getting the addressing right. Here is one of my LDIR routines:

1     0000                              org 0
2     0000
3     0000 21 00 40             ld hl, $4000
4     0003 11 10 00             ld de, $0010
5     0006 01 10 00             ld bc, $0010
6     0009 ED B0                  ldir
7     000B 76                        halt

When I examined $4000 individually I also got the same results (FF if A14 jumper set).

When there's better light I'll take photos of my boards in case anyone can see any soldering problems I've missed. Right now it's early morning and there's a power cut :-p

Any other ideas about next steps?

James

[James Harland]

OK, here are the jumpers, for a sanity check:

[James Harland]

And here are my solder joints (part 1, as I am getting a "your message is too long" error)

[James Harland]

Solder joints part 2:

[Spencer]

Hi James,

I just tried to recreate your exact setup with the same ROM image and same LDIR program. I can confirm that with the jumper set to 000 when looking in 0x0010 onwards I see exactly the same 3A, 31, 30, 34 etc that you get. And all FF with the A14 jumper set.

So something is not right, but it probably is not your setup.  I'm not going to have time to dive deeper in to this until at least tomorrow, so give me a day or two and I'll see if I can work out what's going wrong.

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/72f5cb0f-329a-453a-963a-d2ff5f2e74aan%40googlegroups.com.

[James Harland]

Hi Spencer,

Thank you so much for taking the trouble to do this. In a way it's reassuring that your kit does the same thing, I hope you can get to the bottom of it!

No worries, no hurry. I still need to make the input/output module, and it will take me some time to work all the way through Leventhal on the setup I already have.

Thanks and all the best,

James

[James Harland]

Having seen my own photos, I have also ordered some isopropyl alcohol and am going to get cleaning the PCBs at the weekend :-D

I have been using ethanol as it's easier to get hold of, but it tends to make a sticky mess, so I was lazy with this build. I did scrub the front of the front panel before installing the swtiches and LEDs at least, and now I also have time to clean everything else.

[Spencer]

Hi James,

That loud slapping noise you heard earlier was my palm and forehead coming together.  I now understand exactly what's going on and why. The "why" part is mainly down to me being an idiot!

The data should be in the second bank, requiring A14 being set high. The fact that the ROM is empty there, but there is data in the first bank should have rung alarm bells with me earlier.

The second alarm bell should have been that the data found there all began with a 3 or a 4. Instead of looking those up as op codes, lets see what that are as ASCII characters;

3A  :

31  1

30  0

34  4

30  0

30  0

30  0

30  0

30  0

43  C

33  3

30  0

33  3

34  4

33  3

43  C

33  3

Which matches the start of the hex file on Codeberg perfectly ":10400000C30343C3..."

There are two types of file normally used to burn ROM images; Intel Hex files or Binary files.  Intel Hex files (https://en.wikipedia.org/wiki/Intel_HEX) are human readable ASCII characters which contain the data as well as info about where it goes and check sums etc, but a BIN file is just the raw data from 0x00 - 0xFF.  And what I had done there was to burn the hex file as a binary one!

I really should have spotted that sooner!

So, the good news is that your ROM module is able to read the contents of the ROM perfectly! The bad news is that you will need to put some valid code on there for the Orton 3C to execute.  The routines on the Codeberg page are really just simple example ones, so you are encouraged to write your own routines anyway (and share them back to Codeberg if you think others will find them useful)

Spencer

[James Harland]

Hi Spencer

OK it's good that things make sense and that my system works, though it's vexing not to have those routines, as I was hoping to do some serial out etc.

I do want to buy the ROM burner anyway, though probably not till after pay day.

In the meantime I have completed my Orton 3C build, but have some troubleshooting which is probably due to my soldering this time, but I'll start a new thread for that.

Cheers,

James

[James Harland]

Hi Spencer,

Thanks, I got the ROMS in the mail today - I think that might be a record for things getting to me in Kazakhstan!

I've had a frustrating evening with the Orton 3C ROM, but now I've divined by means of my LDIR routine that although the start of the code (containing the jump tables) is written to the ROM, the areas of ROM that the tables point to are just FFFF. I suppose it's time to figure out how the ROM burner works now!

It's not a big deal - it's fun to use my Z80 skills to troubleshoot this, and I have the burner now so it should be an easy fix.

All the best,

James

[James Harland]

Hi again,

OK this is weird, I've dumped the ROM and compared it with the listing on Codeberg, and everything is where it should be.

I see you've also added a .bin file - thanks for that!

I now need to figure out why I can't seem to read those later addresses on my 3C.

Mysterious...

James

[James Harland]

OK back to the Orton 3C and it seems I really can't access those higher addresses.

If I try to see what is at $4163 (the start of the CLEARRAM routine), by doing this:

1     0000                      org 0
2     0000

3     0000 3A 63 41             ld a,($4163)
4     0003 32 08 00             ld ($0008), a
5     0006 76                   halt
6     0007

I get $FF back to $0008

If I try to addresses starting with $4163 using LDIR:

1     0000                      org 0
2     0000

3     0000 21 63 41             ld hl, $4163

4     0003 11 10 00             ld de, $0010
5     0006 01 10 00             ld bc, $0010
6     0009 ED B0                ldir
7     000B 76                   halt

8     000C

I just get $FF from $0010 onwards

If I try to call $4014 to run the clear routine, the call never returns and no memory is clear.

I have the jumpers set to 100. 

It's really weird that if I use the same routines above at $4000 I do see the data I expect to (C3 03 43 etc)

I don't understand why I can access some but not all of the ROM data.

Thanks,

James

[Peter Onion]

On Thu, 2026-02-19 at 16:18 -0800, James Harland wrote:
>
>
> I don't understand why I can access some but not all of the ROM data.
>
> Thanks,
>
> James

I'm coming late to this thread, but it looks to me like an addressing problem.

I would be checking the connectivity of all the address lines from the pins on the Z80 to
address pins on the ROM it self. Also check for short circuits between adjacent pins on
the Z80, on the backplane and on the ROM.

HTH

PeterO

[Peter Onion]

Another thought....

I think you've got a programmer for the ROM ?

If so, programme it with a pattern that will allow you to determine which address has
actually been read. A sixteen bit count would be a good place to start.

00 00 01 00 02 00 03 00 ...... FF 00
00 01 01 01 02 00 03 00 ...... FF 01
.
.
.
00 FE 01 Fe 02 Fe 03 FE FF FE
00 FF 01 FF 02 FF 03 FF ...... FF FF

That should allow you to check where the data is coming from in the ROM when you read it.

PeterO

[James Harland]

Thank you Peter, so I'm going to try one thing at a time here, firstly your recommendation to check the address lines. So looking at the schematic for the ROM board, I can see the numbers of the address pins. I'm not quite sure which exact ST39SF010 is used here, so I can't easily find the datasheet, but I presume that the numbering starts at one in the top left hand corner and goes round like that. Am I correct so far, and how can I know which pins are responsible for which ranges of addresses?

[James Harland]

Hi Peter,

I found that pins A6 and A7 (or maybe an adjacent pair) were bridged, not on the ROM chip but on the edge connector which connects the backplane to the front panel. When I cleared the bridge, I was able to run the CLEARRAM routine, and inspect other areas of ROM which were inaccessible to me before.

So this seems to have solved the hardware problem, thanks for pointing me in the right direction! I now have a software problem trying to get SPINIT and PUTCH working, but that probably deserves its own thread.

I do have a related hardware question though - how can I understand how the different address pins of the Z80 work? Can someone direct me to a beginner-friendly explanation, ideally in written form as I'm off YouTube for the moment.

Thanks again,

James

[Peter Onion]

Glad to have helped James :-)

I've not done anything RC2014 related for a few months as I've been busy on other projects, so it's nice to at least help someone else with their machine :-)

The signals on the Address lines are the binary representation of the memory location's position in the address space.  Each line represents a power of 2, so A0=1 , A1=2, A3=4, A4=8 ..... A14=16384 and A15= 32768 

So when all the address lines are low, the address is 0000000000000000, or 0x0000 or just 0.

The next  location is 0000000000000001, or 0x0001 or just 1.

Halfway through the address space is 1000000000000000 or 0x8000 or 32768.

The address range to be used by a RAM or ROM chip is selected by performing logical operations on some of the high order address lines.  

For example using A15 OR A14 to drive an active low chip select will stop the chip responding to any addresses where A14 or A15 are high, so only addresses 0000000000000000 to 00111111111111 or 0x0000 to 0x3FFF or 0 to 16383, referred to as the bottom 16K.

Likewise using A15 NAND A14 will select 1100000000000000 to 1111111111111111 or 0xC000 to 0xFFFF or 49152 to 65535, referred to as the top 16K.

HTH,

PeterO

[James Harland]

Hi Peter,

Thanks for the clear explanation. I now also understand why the Z80 can only address 64k natively!

Thanks again,

James