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