Info please! Acorn's in-house large-memory 6502 co-pro

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Sun Dec 01, 2019 10:00 am

Ah yes, CMOS Basic makes sense.

Is the embedded 4.30 exactly as per normal or an interesting variation?

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Sun Dec 01, 2019 3:33 pm

Hi all,

More fun and games this morning...

I've had a go at the 6502 Client ROM changes needed to properly support the 6502 256KB Turbo Co Pro:
- updated boot message
- rom type byte recognition
- osbyte &83, result depnds on the rom type byte
- osbyte &84, result depnds on the rom type byte
- extended addressing for data transfers (so *LOAD/*SAVE work in the 0x10000-0x3FFFF address range)

If anyone is interested, you can see the Client ROM changes here:
https://github.com/hoglet67/6502ClientR ... 7...master

In PiTubeDirect I've added this by extending the "lib6502" Co Processor (written in C), so now there are two versions:
- *FX 151,230,16 - a normal 64K Second Processor
- *FX 151,230,17 - a Turbo 256K Second Processor

Here's the normal version (Co Pro 16):
capture12.png
Here's the turbo version (Co Pro 17):
capture14.png
There's no measurable speed difference between the two, because we don't (yet) have a turbo version of BBC Basic. When enabled, the turbo extensions make the original a few percent slower.

So to test this properly, I've copied the Level 3 File Server sources (attached earlier in this thread) to my ADFS hard disc, and had a go at running the FSASM script:
capture4.png
capture5.png
capture7.png
This runs to completion in about a minute, and the rebuilt executable (version 1.06) matches exactly the version that was in the original ZIP file (md5sum = 203b648f...)

I have no idea if my Client ROM implementation is the same as Acorn's, and it would be fascinating to one day find out, if we ever get to see the original.

In the mean time, if anyone wants to play, here's a development snapshot of the latest PiTubeDirect that includes this:
PiTubeDirect_20191201_1524_dmb.zip
(1.85 MiB) Downloaded 7 times
Dave
Last edited by hoglet on Sun Dec 01, 2019 5:15 pm, edited 1 time in total.

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Sun Dec 01, 2019 4:40 pm

Fantastic!

(No reason presumably why we couldn't go all the way up to 16MByte as an option?)

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Tue Dec 03, 2019 10:09 am

Hmm, I just thought of a wrinkle, which makes the implementation in TTL a little more complex than I'd supposed.

As the box aims to provide 2 MSBs to the address bus in the case of an indirect indexed access, there's the possibility of a carry from the 8 bit Y index all the way into the 2 extra bits. To sweep this under the carpet, take the 256k to be 4 banks. Or, maybe, never allocate objects in the final page of a bank.

To do the job properly, I think you'd need the TTL machinery to do something like this:
- detect byte 2 being fetched as FF and yet output as 00
- increment the top two bits

Possibly an extra cycle could be taken for this case - otherwise it's a bit of a mad panic within a single cycle. I do notice the DRAMs are 150ns, compared to the probable 333ns 6502 cycle time, so maybe the first phase of the final cycle is set aside for this kind of adjustment.

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Tue Dec 03, 2019 11:08 am

BigEd wrote:
Tue Dec 03, 2019 10:09 am
Hmm, I just thought of a wrinkle, which makes the implementation in TTL a little more complex than I'd supposed.

As the box aims to provide 2 MSBs to the address bus in the case of an indirect indexed access, there's the possibility of a carry from the 8 bit Y index all the way into the 2 extra bits. To sweep this under the carpet, take the 256k to be 4 banks. Or, maybe, never allocate objects in the final page of a bank.
I assumed that the real hardware didn't support this indexing across 64KB boundaries.

At least, that's how I implemented it in lib6502:

Code: Select all

    ea = (ea + Y) & 0xFFFF;                                     \
    if (turbo) {						\
      ea += ((MEM(((tmp + 1)&0xFF)+0x300)&0x03) << 16);		\
    }								\
https://github.com/hoglet67/PiTubeDirec ... 502.c#L243

A related question is whether the Extended 6502 Client ROM allowed data transfers to cross a 64KB booundary. I suspect yes, so that's what I implemeted.

Dave

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Tue Dec 03, 2019 7:16 pm

Hi all,

This afternoon Ed and I spent an hour looking at the photos of the Extended 6502 Co Pro, and comparing these with the original and it's schematics.

Almost all of the existing ICs are carried forward and retain their original IC numbers (IC1-IC27), suggesting most of the original 6502 Co Pro is unchanged. The new functionality appears to be implemented by:

Code: Select all

IC27            74LS153         Dual 4-input mux
IC28            74LS32          Quad 2-input OR
IC29            74LS74          Dual D-type FF
IC30            74LS02          Quad 2-input NOR
IC31            74LS27          Triple 3-input NOR
IC32            74LS175         Quad D-type FF
IC33            74LS138 (?)     1-of-8 decoder
IC34            74LS00          Quad 2-input NAND
IC35            74LS02          Quad 2-input NOR
IC36            74LS74          Dual D-type FF
IC37            74LS164         8-bit Serial-In Parallel Out shifter
The only part in the original 6502 Co Pro that appears to have been dropped is IC27 (a 74S74). This is now a 74LS153.

We speculate the IC37, the shift register, is used for overall timing by generating a set of delayed versions of SYNC.

Dave

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Tue Dec 03, 2019 8:28 pm

Good info collection Dave!

To correct a previous idea of mine, it seems both the extended and the regular machine have -15 DRAMs, so that's no difference.

User avatar
KenLowe
Posts: 760
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by KenLowe » Tue Dec 03, 2019 10:05 pm

hoglet wrote:
Tue Dec 03, 2019 7:16 pm
The only part in the original 6502 Co Pro that appears to have been dropped is IC27 (a 74S74). This is now a 74LS153.
If it helps any, my 6502 Co Pro is missing IC27 completely!

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Wed Dec 04, 2019 8:35 am

What might a dual 4-way mux be useful for? It just might be useful for selecting the top two address bits: zero because non-turbo mode, zero because not a special cycle of a special opcode, bit from page 3, inverse of bit from page 3... If indeed the memory is flat not banked, I think we'd need to see enough logic to detect FF (early, on the databus) and 00 (late, on the address bus). But in this case I'd expect to see more wide gates: the triple 3 NOR is handy, but where's the other case? A bunch of 2-input gates is going to need three layers of logic. Maybe there's logic enough, and time.

awilliams
Posts: 14
Joined: Sun Feb 22, 2015 10:51 am
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by awilliams » Wed Dec 04, 2019 10:23 am

I am jut going to add this in case it helps.

I believe that whoever explained this thing to me in the first place also said that the only reason it worked is because of undocumented behaviors of the CPU during its internal cycles. I believe its what it puts out on the address bus that is important, and that what it does it put the same address out twice.

This may be where you get an extra cycle from to do the page correction discussed earlier.

I apologize if the quote is not about this device but I can't think of anything else that it could be, but nor can I remember with certainty that it was.

Alan

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Wed Dec 04, 2019 1:39 pm

An interesting idea. We don't know exactly how this box is built, but we do know that three-byte addressing carries a small performance penalty, so I very much expect to see RDY brought into play to stall the affected instructions at least for one cycle.

It might be argued that the cycle-by-cycle behaviour of the 6502 isn't documented, beyond the cycle counts of each instruction. And by that view, counting cycles and picking out behaviour accordingly is relying on undocumented behaviour... but I think my take wouldn't quite be that. (There could hypothetically be a 6502 implementation which fetches the two bytes of an indirect pointer in the other order, which would surely cause havoc with the kind of cycle-counted trickery which we expect to see in the Expanded machine, but for good reasons there hasn't been such an implementation.)

User avatar
1024MAK
Posts: 9389
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by 1024MAK » Wed Dec 04, 2019 2:03 pm

In digital computer systems, mux chips are typically used for changing the source of address bits presented to the memory chips.

Ed are you speculating that this mux chip is doing something other than multiplexing the extra address bits to the DRAM multiplexed address bus?

More information would make this a lot easier... access to the board would have been nice, but alas... :(

Mark

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Wed Dec 04, 2019 2:15 pm

Indeed, it could well be that the mux is for RAS and CAS multiplexing. Although, why a dual 4 way mux?

It would be good if we can get more information about the device - it's possible the seller, when they receive the box, will check in here or somewhere and help to answer some questions.

If anyone has any Turbo mode software, or knows of any, that could be very handy too. TURMASM is the first and only, so far as I know.

(It might be that we can learn something useful by disassembling 65ARTHURT, but there's quite a lot of it.)

User avatar
jgharston
Posts: 3755
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by jgharston » Wed Dec 04, 2019 6:21 pm

It could be that the 24-bit (zp),Y addressing mode is essentially a 64K zero-page addressing mode, in that the top eight bits remain fixed and the addressing wraps within the 64K, just as LDA &FF,X will access &00 if X=1, I would expect the equivalent of LDA &02FFFF,Y to access &020000 if Y=1.

ie:
LDA #&FF:STA &A8
LDA #&FF:STA &A9
LDA #&02:STA &03A8
LDY #&01
LDA (&A8),Y ; I would expect this to access &020000

I would be pleasantly surprised if it didn't, but a 64K wraparound would fit the conceptual structure of the 6502.

(On a tangent, various 6502 forums speculate on fantasy 32-bit 6502s, and true to form, back in the 1980s I "designed" a 32-bit 6502 instruction set here: http://mdfs.net/Docs/Comp/6502/32bit )

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Wed Dec 04, 2019 6:36 pm

(Not to steal Dave's thunder, but he reports that 65ARTHURT, the emulator posted upthread by awilliams, and the best reference we have for the behaviour of the Extended second processor, does indeed wrap within 64k banks - this is not a flat memory model!)

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Wed Dec 04, 2019 6:48 pm

BigEd wrote:
Wed Dec 04, 2019 6:36 pm
(Not to steal Dave's thunder, but he reports that 65ARTHURT, the emulator posted upthread by awilliams, and the best reference we have for the behaviour of the Extended second processor, does indeed wrap within 64k banks - this is not a flat memory model!)
Yes indeed that does seem to be the case:
em1.png
em2.png
em3.png
0-7 Are the top 8 bytes of the ROM.

8-15 Appear to have wrapped back to page zero.

In other news, yesterday we extracted the Tube ROM from the 65ARTHURT emulator. Here's a quick disassembly:
https://github.com/hoglet67/6502ClientR ... entrom.asm

This ROM is not the same as the real hardware, as there are plenty of points where the implementation is just a stub (with an RTS) where the emulator would take over. And there is no tube access at all. But it's a useful reference to see where bits of Page 3 are setup. Search for L003.

Dave

SteveBagley
Posts: 206
Joined: Sun Mar 15, 2015 8:44 pm
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by SteveBagley » Wed Dec 04, 2019 7:04 pm

Hmm, I'm not sure if IC33 is a 74LS138. If it is, then you have one of its outputs (pin 11, /O4) connected to the output of a 74LS27 (IC31?, pin 8 ) which doesn't seem to make any sense…

If IC33 is a 74LS138 then I wouldn't be surprised if it is being used to decode the instruction's addressing mode. The relevant 6502 instructions (I think) are all encoded aaabbb01, where bbb encodes the addressing mode. The (ZP),Y addressing mode is encoded as bbb equal to 100, and there's a track coming out of the 74LS138's /O4 pin (but to the output of the OR gate)…

Steve
Last edited by 1024MAK on Wed Dec 04, 2019 9:03 pm, edited 1 time in total.
Reason: Space added between the 8 and the ) to prevent it turning into a cool emoji...

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Wed Dec 04, 2019 7:29 pm

SteveBagley wrote:
Wed Dec 04, 2019 7:04 pm
Hmm, I'm not sure if IC33 is a 74LS138. If it is, then you have one of its outputs (pin 11, /O4) connected to the output of a 74LS27 (IC31?, pin 8) which doesn't seem to make any sense…
That's a good observation.

IC33 is very hard to read on the photos, but it looks like 74LS13<something> and has 16 pins. Or maybe 74LS15<something>

From wikipedia:
74ls13x.PNG
74ls15x.PNG
SteveBagley wrote:
Wed Dec 04, 2019 7:04 pm
If IC33 is a 74LS138 then I wouldn't be surprised if it is being used to decode the instruction's addressing mode. The relevant 6502 instructions (I think) are all encoded aaabbb01, where bbb encodes the addressing mode. The (ZP),Y addressing mode is encoded as bbb equal to 100, and there's a track coming out of the 74LS138's /O4 pin (but to the output of the OR gate)…
I was thinking the same. The patterns than need decoding are:
- xxx10001 (ZP),Y
- xxx10010 (ZP)

But now I doubt this is a 74LS138.

Dave

User avatar
IanS
Posts: 1059
Joined: Mon Aug 31, 2009 6:02 pm
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by IanS » Wed Dec 04, 2019 7:46 pm

hoglet wrote:
Wed Dec 04, 2019 7:29 pm
SteveBagley wrote:
Wed Dec 04, 2019 7:04 pm
Hmm, I'm not sure if IC33 is a 74LS138. If it is, then you have one of its outputs (pin 11, /O4) connected to the output of a 74LS27 (IC31?, pin 8) which doesn't seem to make any sense…
That's a good observation.

IC33 is very hard to read on the photos, but it looks like 74LS13<something> and has 16 pins. Or maybe 74LS15<something>

From wikipedia:
74ls13x.PNG
74ls15x.PNG
There seems to be reference to the 74HC131 being a 3-to-8 decoder with latch, I pressume the LS chips is the same function. Does that make more sense?
Attachments
74hc131.pdf
74HC131 datasheet
(267.79 KiB) Downloaded 2 times

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Wed Dec 04, 2019 7:58 pm

IanS wrote:
Wed Dec 04, 2019 7:46 pm
Does that make more sense?
Pin 11 in the '131 is still an output, which then drives another output.

User avatar
jgharston
Posts: 3755
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by jgharston » Wed Dec 04, 2019 8:10 pm

hoglet wrote:
Wed Dec 04, 2019 6:48 pm
In other news, yesterday we extracted the Tube ROM from the 65ARTHURT emulator. Here's a quick disassembly:
https://github.com/hoglet67/6502ClientR ... entrom.asm
Looks very similar to the 65Tube client code which is v0.64. I'll copy it to my laptop and do some comparisons while watching Win10 builds.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Wed Dec 04, 2019 8:18 pm

jgharston wrote:
Wed Dec 04, 2019 8:10 pm
Looks very similar to the 65Tube client code which is v0.64. I'll copy it to my laptop and do some comparisons while watching Win10 builds.
That's interesting.

Was this extracted from an actual "65TUBE" emulator disk image?

Did 65TUBE also implement extended addressing then?

Dave

User avatar
hoglet
Posts: 8679
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by hoglet » Wed Dec 04, 2019 8:29 pm

hoglet wrote:
Wed Dec 04, 2019 8:18 pm
Was this extracted from an actual "65TUBE" emulator disk image?
Looks like it came from 65TUBE on RISC OS Application Disc 2.
hoglet wrote:
Wed Dec 04, 2019 8:18 pm
Did 65TUBE also implement extended addressing then?
Here's the fragment of code for LDA (zp),Y

Code: Select all

// Opcode B1 -
    3930:   e4da0001    ldrb    r0, [sl], #1
    3934:   e7f0100b    ldrb    r1, [r0, fp]!
    3938:   e5d00001    ldrb    r0, [r0, #1]
    393c:   e0810400    add r0, r1, r0, lsl #8
    3940:   e0800c28    add r0, r0, r8, lsr #24
    3944:   e3c00801    bic r0, r0, #65536  ; 0x10000
    3948:   e7db1000    ldrb    r1, [fp, r0]
    394c:   e1a06c01    lsl r6, r1, #24
    3950:   e3360000    teq r6, #0
This is only accessing 64K of memory.

So it's curious that the TUBE ROM has the Page 3 extensions.

Dave

User avatar
1024MAK
Posts: 9389
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by 1024MAK » Wed Dec 04, 2019 10:24 pm

SteveBagley wrote:
Wed Dec 04, 2019 7:04 pm
Hmm, I'm not sure if IC33 is a 74LS138. If it is, then you have one of its outputs (pin 11, /O4) connected to the output of a 74LS27 (IC31?, pin 8 ) which doesn't seem to make any sense…

If IC33 is a 74LS138 then I wouldn't be surprised if it is being used to decode the instruction's addressing mode. The relevant 6502 instructions (I think) are all encoded aaabbb01, where bbb encodes the addressing mode. The (ZP),Y addressing mode is encoded as bbb equal to 100, and there's a track coming out of the 74LS138's /O4 pin (but to the output of the OR gate)…

Steve
I’m not certain, but it looks more like a 74LS151... or at least a 74LS15<something>...

Mark

SteveBagley
Posts: 206
Joined: Sun Mar 15, 2015 8:44 pm
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by SteveBagley » Thu Dec 05, 2019 12:35 am

BigEd wrote:
Wed Dec 04, 2019 2:15 pm
Indeed, it could well be that the mux is for RAS and CAS multiplexing. Although, why a dual 4 way mux?
There's at least three output values it needs to feed A8 on the memory chips: 0 (during refresh cycles, the data sheet seems to suggest you still only need to cycle A0-A7 to refresh the DRAM chips), A17 (during CAS), and A18 (during RAS). The rest of the memory signals are generated as per a normal second processor via the 81LS95.

As for why it’s a dual mix, is it as simple as there isn’t an alternative chip with just a single 4-input mux they could use?

Steve

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Thu Dec 05, 2019 9:17 am

Yes, it could that the second mux is unused. Dave's experiments with 65ARTHURT do seem to show that there's no effort to carry into the third byte, so I should stop looking for evidence...

... and yet, I realised this morning that I was wrong to think comparisons against FF and 00 are needed. It's enough to see 1xxxxxxx fetched from zero page and 0xxxxxxx put on the databus.

So the one possible glimmer of hope is that 65ARTHURT behaves differently when a Turbo mode binary is loaded than when a 6502 binary is loaded - that the hardware has a mode bit, which controls not the access to high memory using non-zero values in page 3, but the operation of a carry into the third address byte, providing a flat memory model.

User avatar
Rich Talbot-Watkins
Posts: 1556
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by Rich Talbot-Watkins » Thu Dec 05, 2019 9:36 am

I think it's far less useful if it can't present a flat memory model. But I'm not sure how the timing could work to handle the bit 15-16 carry (which as you say would only need to check a single bit discrepancy).

I think potentially the CPU would need to be stopped twice - first time after loading zp+1 to load &300+zp+1, and second time to perform bit 15-16 carry if necessary. I think there's a small problem here in that I think RDY low is ignored if R/W is low (as it would be in the final cycle of a store), meaning it would be too late to perform an adjustment. I guess you could just buffer all the signals, but it sounds like quite complicated logic.

Also the way that load instructions can skip their final read cycle makes things more complex, so you'd need to check whether the final cycle was a SYNC instead, in order to skip address fixup.

User avatar
BigEd
Posts: 2690
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by BigEd » Thu Dec 05, 2019 10:03 am

(Don't worry about RDY and write cycles - that's only a problem with the NMOS 6502, and here we're talking about a CMOS part.)

Indeed, it might take an extra cycle for the carry. There is a little time available though, if the affected address bits are the second to be presented, in the CAS part of the address. There's only a need for a mux to switch, between the original and the (optionally) (pre)incremented version, controlled by A15.

User avatar
jgharston
Posts: 3755
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by jgharston » Thu Dec 05, 2019 4:17 pm

jgharston wrote:
Wed Dec 04, 2019 8:10 pm
hoglet wrote:
Wed Dec 04, 2019 6:48 pm
In other news, yesterday we extracted the Tube ROM from the 65ARTHURT emulator. Here's a quick disassembly:
https://github.com/hoglet67/6502ClientR ... entrom.asm
Looks very similar to the 65Tube client code which is v0.64. I'll copy it to my laptop and do some comparisons while watching Win10 builds.
Yes, I've gone through the disassembly, Tube v0.44 from Arthur65 is nearly identical to Tube v0.64 from 65Tube. v0.64 has some optimisation (multiple calls to SkipSpace) and a bit of shuffling around to remove some long jumps. But otherwise, they are functionally identical.

Memory rings a bell, and I think in essence Arthur65 is the non-module 6502 Tube emulator and 65Tube is the RISC OS module 6502 Tube emulator. I also wonder if the version number indicates 0.X4 with x.4x being the Arthur65 code and x.6x being the 65Tube code.

Another thought is whether in adding the module functionality to convert Arthur65 into 65Tube whether/when they removed the 24-bit indirect addressing mode. As hoglet posted above, at least some versions have it removed.

Edit: I don't have FTP access here, I'll upload the commented disassembly when I get home later.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

tom_seddon
Posts: 348
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Info please! Acorn's in-house large-memory 6502 co-pro

Post by tom_seddon » Thu Dec 05, 2019 9:14 pm

Rich Talbot-Watkins wrote:
Thu Dec 05, 2019 9:36 am
I think it's far less useful if it can't present a flat memory model. But I'm not sure how the timing could work to handle the bit 15-16 carry (which as you say would only need to check a single bit discrepancy).
Interesting snippet about BAS128 from http://www.rougol.jellybaby.net/meeting ... ulFellows/:
By finding all the places in the assembly language of the BASIC interpreter where it accessed the source code of your program or its variables, you discovered they were all done with one particular mode of addressing, the 'indirect comma y' form of addressing, so we could do that and stick an extra byte of address in there and poke a hardware register in order to let you access these chunks as if it was a 64K address space.
So perhaps this system could have worked quite neatly with a suitably modified BBC BASIC interpreter. You've essentially got 4 x 64 K banks of memory, of which you can use bank 0 for the usual copro stuff (parasite OS, BASIC interpreter, ordinary zero page, stack, page 3), bank 1 for the BASIC program (PAGE=0, HIMEM=65536!); bank 2 for the variables... and you've still got bank 3 free!

Maybe you could organise for assembled code to go there. P%=&38000 if you're writing a ROM, or something. No idea whether BASIC uses separate zero page pointers for that though. There's probably enough space left in bank 0 for most purposes anyway.

--Tom

Post Reply