65816 + DE0Nano + Tube project notes

[jgharston]

I was thinking the same about OSWORD etc. I'm seriously looking at having two APIs. The normal JSR FFXX one and maybe a Native Mode one using the COP instruction to do something like SWIs in RiscOS, maybe using the stack as for passing instructions?

That's what I did with the 6812 client. There's the normal jump block at &FFxx, SWI is the equivalent of BRK to do errors, and TRAP n is the equivalent of doing a SWI/SVC/EMT.

I think the simplest thing would be to have A=function, X16=>control block, and specify the OSFILE and OSRDLN control blocks to have 32-bit string address. I don't like using the stack to pass parameters to MOS entries, as it's easy to forget to put/remove the correct number. It's ok within a compiled program as the compiler is controlling all the aspects of the caller/callee, but when 'exiting' the program to make a low-level MOS call I think registers are a better method.

[dominicbeesley]

Thanks lads,

I've hopefully given the thread a more meaningful title.

Thanks, JGH for your thoughts on this - I need to have more of a look at your 6809 stuff.

The trouble with passing arguments in registers on the 816 is that you need to be able to pass 24 bit addresses for things or limit a lot of things to low memory. I know what you mean about stack confusion though. Just spent half an hour faffing with a problem caused by a rogue pha...

Anyway progress today: I've added a bodge pull up to abortb and its a lot better behaved - involved spot soldering a thin wire-wrap wire to the inside of the PLCC chip holder and leading it out to a manhattan'ed resistor on a VCC track...bound to get snapped off at some point but hopefully I'll have plucked up the courage to get a proper board made by then.

Got the interrupt service routines working though not thoroughly tested in native mode. All a little bodged at the moment - it just pushes all the 16 bit registers, switches to emulated mode and makes a pretend stack frame before jumping into the original interrupt handler. It wouldn't work right at first until I remembered that in Native mode there's no B flag causing all my IRQs to turn into BRKs...

If I get a chance tomorrow I'll be rewriting all the MOS entries to run in native or emulated mode...

[jgharston]

The trouble with passing arguments in registers on the 816 is that you need to be able to pass 24 bit addresses for things or limit a lot of things to low memory.

d'oh, of course. I'd typed X16/Y16=>control block then for some reason edited out the Y16.

[dominicbeesley]

While the baby sleeps I've spent another hour and (slowly) got one OS routine (OSWRCH) to be native/emulated mode agnostic and write a working test program to check that it works.

I'm not sure what to do with the vector calls i.e. WRCHV. For now I'm going to make them all run with a wrapper that switches back to emulated mode. This will be better for compatibility with old programs but will by necessity slow the OS down a little and add another wodge of extra ROM...

[dominicbeesley]

I've not been idle but I've got a bit stuck...

I've patched up all the OS wrappers to be mode agnostic though I've not yet thoroughly tested these and suspect that they will need some tweaking especially OSWORD and OSGBPB.

I've also got BASIC "sort of" working in native mode. In theory that should be fairly simple but in practice BASIC does a lot of messing around with the stack and in Native mode if you set the stack pointer with an 8 bit TXS or TXA it gets set to $00XX not $01XX so some faffing with that was in order.

I'm now stuck on a but of a knotty problem. BASIC seems to work except for floating point multiplies which give erratic results. I suspect that there is possibly a problem with my stacking code which might be crashing the FP zero page registers or stack contents...but it might be a more subtle problem caused by the small differences in behaviour between native and 6502 mode...

Anyway I suspect my next task will be to create a simple monitor program to allow me to set breakpoints and examine registers and memory. At the moment I've been tracing using a LA5034 Logic Analyser (which is utter junk as the bus value triggers don't work so I've had to rig up an extra TUBE register for debug info!) and a lot of deduction as I can't examine memory with that just what appears on the buses. I wish I'd had room for all the address lines into and out of the DE0Nano then I'd be able to rig up some magical JTAG single-stepping monitor via USB...

Before I do a couple of questions to answer
- Is the memory between C000 and F800 usually "free" on a co-pro, could I put my monitor in there?
- Are there any parts of basic that are position dependant - I've checked through the code, but only skimmed, and I thing the JGH's disassembly of BASIC 4 has all positional stuff set up using proper lables...

D

[jgharston]

Is the memory between C000 and F800 usually "free" on a co-pro, could I put my monitor in there?

No. A 6502 CoPro running HiBASIC has BASIC at &B800 to &F800. If you want the 65816 CoPro to be able to run 6502 code in 6502 mode, then it needs to be able to run code at &B800-&F800.

As the 6502 Tube Client copies itself to RAM on startup you could have the monitor in &F000-&F800, copied there on startup from ROM at &F000-&F800 as the "startup" program. Any other program would get loaded on top of it, just as anything else loaded/run into that area of memory.

The startup code would have to make sure it didn't just blindly copy everything &F000-&FFFF from ROM to RAM, as on a Soft Break nothing gets copied into the CoPro, the Client just re-enters the current program. If the current program is HiBASIC at &B800-&F800 (or VIEW which moves itself to &D000-&F800, or any othe HiLanguage) if the startup code blindly copied the monitor to &F000-&F800 it would be trashing whatever was already there.

What you could do in the startup code is, when checking for the startup acknowledge, if it says 'enter code', if the entry address if below &B000 then it's a reasonable assumption that you can copy the monitor code to &F000 as &B000 plus 16K gets to &F000.

Using the 6502 Client as a reference, at EnterCodeReset, do something like:

Code: Select all

  .EnterCodeReset
  CMP #&80        :\ Is there code to enter?
  BNE CmdOSLoop   :\ No, enter monitor * prompt
  LDA &F7         :\ Get top byte of ADDRESS to enter
  CMP #&B0        :\ Do we have enough space for the debugger?
  BCS NoDebugger
  \ Some code here to copy debugger to &F000-&F7FF
  .NoDebugger
  CLC             :\ CLC=Entering at RESET
  BCC EnterCode   :\ Jump to enter code

The 'copy debugger code' bit might be a bit fiddly, as once you've got to this point the ROM has been paged out and it doesn't get paged back in again until RESET.

Are there any parts of basic that are position dependant

Yes, all of it. But that's dealt with by using an assembler to re-assemble it with a different ORG. I don't think there's anything that forces it to be page-aligned, but I've always assembled BASIC at an &xx00 address anyway.

[dominicbeesley]

Thanks JGH,

I thought I'd replied to this already.

Sorry, I must have been tired when I posted the last set of questions as they weren't very clear.

I meant to ask is that memory area clear during "normal" not "Hi" basic operation. After some investigation it seems to be! At some point when I've got it working I'll make the monitor so it can sit in one of the other banks out of the way of all the 6502 stuff. At the moment I'm just getting together something that I can set a breakpoint (using a COP instruction) in the code and get reigster / memory dumps.

I can't run HiBasic at present anyway as the client rom has got a bit bloated already needing an extra page of memory to fit the native vectors and the extra mode switching code around the OS calls - I'm hoping later to have a look through and with some work should be able to get it back down to the original size again by using the new move/copy instructions.

I was going to ask about the "current" program thing. Reentering that after a BREAK makes sense when it is a ROM (say BASIC) but not so much sense for a transient *COMMAND...but if that's the way its meant to work...

As to the position dependent question I should have said alignment dependent although it seem that the big tables for jump and tokens seem to be happy to be moved around...

So far I've got a monitor that dumps memory contents. Hopefully some time today I'll get a chance to make it work with breakpoints...

Thanks

D

[dominicbeesley]

Slow progress yesterday. Just managed to get started on some coding after spending all afternoon in A&E with the baby...test my new breakpoint setting code when the machine when pft!

It had been playing silly buggers and randomly resetting for a while. This time the PSU made a weird click and squeal noise and now the motherboard's a bit dead. PSU output still measured ok but must have spiked and fried something. So back to the previously nearly but not quite working beeb. That had problems with the user VIA. Chip swaps didn't help but always had problems with D7 & D6 being zero. After a lot of poking around and measuring last night it turned out to be the chip holder. I've bodged it (bent 6522 pins inwards) for now but will have a go at fixing it properly when I get time.

Anyway after all that I didn't have much time but I can now do memory dumps, execute code and set breakpoints. Also I fixed more OS code to make it Emulated / Native agnostic and (mainly OSCLI and OSBGET).

Still to do is the code for handling the COP vector and saving all the regs. Then code for restoring and continuing. I'm not sure how to actually handle the continue so that it will stop again on the next pass. I guess I'll have to put the instruction back and replace the next instruction with a COP then when that breaks put the COP back on the previous instruction and put the second COP back to the original instruction and continue....all a bit complicated if the instruction happens to be a jsr, jmp or b**....I might just make it so only non-branching instructions can be set as a break point for now.

[jgharston]

Sorry for the delays reply, I've been wallpapering...

I was going to ask about the "current" program thing. Reentering that after a BREAK makes sense when it is a ROM (say BASIC) but not so much sense for a transient *COMMAND...but if that's the way its meant to work...

Yes, to me that seems just so wrong. It's how it does work, but I can't make myself beleive that that's how it's meant to work.

It would make sense if code with a header (eg a ROM) became the current program, but raw code didn't. That would mean *basic, *run basic, *load basic/*go addr would make it the current program and re-enter it on break, but *proggy, *load proggy/*go addr would not become the current program. As it is, it means that if you press Break while a transient program is running, the transient program is re-entered. Even worse, if the transient program generates an error, it remains the current program even though the error handler has taken you back to the calling program.

Save this to load to &00000780: BRK:BRK:EQUS "Hello!":BRK and *run it. Press Break. Argh!

This seems to me to be so much a bug that I've really wanted to modify that part of EXECUTE so that raw code does not become the current program. I've accidently propagated this behaviour into the 6809, 6812 and PDP11 clients, though I think I've documented the 6809/6812 clients as saying that raw code does not become the current program.

Also I fixed more OS code to make it Emulated / Native agnostic and (mainly OSCLI and OSBGET).

Single character/byte I/O should be the easiest to make agnostic, as you're just passing the 8-bit contents of the A register. The control block calls are likely to be fiddlier.

Still to do is the code for handling the COP vector and saving all the regs. Then code for restoring and continuing. I'm not sure how to actually handle the continue so that it will stop again on the next pass. ...

Are you trying to use COP to do single-stepping? Yes, for that you need to calculate how long the instruction you're stepping through is. I think what I'd do is:

Set breakpoint:
copy addr?0, addr?1, addr?2, addr?3 to store
copy COP to addr?0

COP handler:
get return address from stack, subtract two to get COP address
copy store to addr?0, addr?1, addr?2, addr?3
display information to user and wait for response
examine addr?0 to work out instruction length
store COP at addr+length
jump back to addr

Yes, if there's a branch you'll have to decide what to do with it.

All the best to the baby.

[dominicbeesley]

Thank JGH,

I'm glad you agree with the "current program" thing. I may change it soon as it's starting to annoy me!

As you say the simple OS calls are OK. Anything that uses IRQs or NMI's has to either wrap them up carefully or make sure everything is in emulated mode. It gets quite a challenge if the stack has been moved at all or the code or data is in a different bank. For now I'm still in the first 64k but when I get round to redoing BASIC in earnest I want to relocate the stack to 8000 and use the CPU stack functionality instead of BASIC's own stack - should be a lot faster.

Thanks for confirming my thinking about COP's. So far I've got breakpoints working as a one-shot i.e. they get disabled once they're hit. I think the fancy stuff will have to go on the pile with the other round tuits.

Baby's ok (green stick fracture) though she was awake until 3.30 last night. She sat, quietly, on my knee helping with my programming...I'll make a coder of her yet!

[dominicbeesley]

Yay! Just got BASIC's floating point routines working properly.

I discovered the problem was that there's a table at the end of the ROM containing constants for FP, lots of bits of code only encode the low byte of the pointer into this the high byte is assumed...that's what was causing problems. I've further bodged the ROM by moving the whole tokens table out into "extra" memory at C000-C800 whilst I rework the rest of the ROM to try and get it faster and to fit back into a normal ROM sized ROM.

Whilst fiddling I've found a suspect" reference in the original basic 4 src from MDFS.net (which is what I've been using as a basis rather than the faster 4.. Correction below.

Code: Select all

2058: JSR L8CDF:BEQ [u]L[/u]9141 :\ Get next non-space char, if '#' jump to do PRINT#

So far I've just been trying to get the ROM to work in native mode and made a couple of tweaks to the stack/unstack code to use the MVN instruction and already things are getting very slightly faster overall. Next I'll have a "play" with the BASIC ROM to try and get it going a bit faster.

Disappointingly, all this was achieved without the use of the new monitor software!

D

[1024MAK]

Carefull...
If you are going to use a eight followed by a ")", stick a space in between ( like this 8 ) otherwise the forum will convert it to a

Mark

[dominicbeesley]

Oops, not my only mistake today - turns out I haven't fixed the FP at all, I had copied an old version of the basic SSD to the machine!

D

[Wookie]

Carefull...
If you are going to use a eight followed by a ")", stick a space in between ( like this 8 ) otherwise the forum will convert it to a

Alternatively stick between [ code ] [ /code ] tags eg...

Code: Select all

8)

[dominicbeesley]

Thanks lads, I'll try and remember not to accidentally put in smilies. I do think that it's a bit daft having them automatic on technical forums where its very likely that numbers and symbols will be in proliferation.

Anyway back to the matter in hand. I've worked out what the problem is, there's a bit of code in the mulitply routine that unpacks a floating point mantissa to an integer (i.e. reverses the bytes) which uses LDA ZP, X with X being a "negative number" i.e. it wraps in zero page. In native mode on the 65816 it doesn't wrap but continues onto the next page. I'm going to have a go at rewriting that part this morning.

Code: Select all

		ZP_INT_WA	= $2A
		ZP_FP_WA_A	= $2E
		ZP_STRBUFLEN	= $36
		ZP_GEN_PTR	= $37
		ZP_NAMELENORVT  = $39
		ZP_FP_WA_B	= $3B
		ZP_FP_TMP	= $43
		ZP_FP_TMP_PTR1	= $4A

		LDX #$F8
		LDY #$04
		; copy $31..34 to $45..42 i.e. mantissa to FP_TMP - 1
		; i.e. A,3..A,6 => B,10..B,7
@lp1:	LDA ZP_FP_WA_A + 3 + 8,X	;HERE
		STZ ZP_FP_WA_A + 3 + 8,X    	;HERE
		STA ZP_FP_WA_B + 6,Y
		INX
		DEY
		BNE @lp1
		STZ ZP_FP_WA_B + 1
		STZ ZP_FP_WA_B
		STZ ZP_NAMELENORVT + 1
		BRA LA735

will need to goto something like

Code: Select all

LDX #$0
		LDY #$04
		; copy $31..34 to $45..42 i.e. mantissa to FP_TMP - 1
		; i.e. A,3..A,6 => B,10..B,7
@lp1:		LDA ZP_FP_WA_A + 3,X
		STZ ZP_FP_WA_A + 3,X
		STA ZP_FP_WA_B + 6,Y
		INX
		DEY
		BNE @lp1

There's a bit more to it than that i.e. X continues to be used in that way in the rest of the mul routine so a bit of poking about should fix it. Then I'll need to search through the rest of the code to check for similar incompatibilities. Should keep me quiet whilst my hangover subsides and I wait to tackle replacing the wheel hub on my Land Rover...

[dominicbeesley]

Yay, that worked. unfortunately the machine then packed in just as I was testing it. Another dead beeb. Will try and get the thing working again later today if I get the chance.

I now have 5 broken beebs...I must be able to canibalise them to make one that works reliably...I suspect their encounter with dry-rot a few year ago has reduced their MTBF a little...

[paulb]

Thanks lads, I'll try and remember not to accidentally put in smilies. I do think that it's a bit daft having them automatic on technical forums where its very likely that numbers and symbols will be in proliferation.

There's also the "Disable smilies" checkbox below the message panel (in the current theme). I noticed that after posting a lot of bracketed numerals a few weeks ago.

[dominicbeesley]

Well spotted.

Anyway, I got the beeb #1 working again...after much headscratching. It seems that two 6502 pins were not making contact (RES and A13) with the socket plus A13 of the OS rom socket has a dry joint. Funny how all three went at the same time! My new logic analyser is a huge help...if only I'd had one in the 80's!

Just run a few more tests. The SPEED and SPEED4 programs run as does my Mandelbrot Set test prog. If I get a chance tomorrow I'll be soldering some better IC sockets and have a go at some optimisations in BASIC.

[jgharston]

Thank JGH,
I'm glad you agree with the "current program" thing. I may change it soon as it's starting to annoy me!

I've updated the 6502 Client code so that raw code is not made the current program, plus some bugfixes, optimisations and additions. Set UPDATE1%=TRUE to build the updated version.

I also sketched out the EXECUTE routine for a 6502/65816 client: execute, outlining what it needs to do, incorporating the updated 6502 Client methodology.

[dominicbeesley]

Thanks JGH,

I'll have a look at your stuff when I get a chance. Unlikely to be this week as I'm off on my holidays (visit Chernobyl to see the reactor before the new dome is finishes) and my re-soldering of the sockets on my last working machine has made it into my last non-working machine! I did do it in a bit of a hurry so suspect one of the holes hasn't flowed to both sides of the PCB. The R/W signal is doing some weird stuff with it seemingly going low fetching the opcode for STA instructions...but still fetching the opcode, weird!

It will certainly be nice to be able to run a transient command without having to faff. I'll then have a go at finishing off my monitor software.

I did have a go at "optimising" the BASIC rom by using the new 16 bit instructions and block moves....results were very disappointing. I first attacked the search for line number code as I thought that that would be an easy win but try as I might the best I could achieve was parity on the SPEED4 test with some tinkering I could get the code a couple of bytes shorter but not any faster. I'll have a go at the integer arithmetic functions as they should be simple to get some sort of win on things like 32 bit multiply / divide / etc. Floating point will be a bit more tricky as the mantissa is big-endian and so not conducive to 16 bit operations without a lot of byte swapping.

Hopefully, as I get my eye in, I should be able to get some improvement, but I can now see why Acorn developed the ARM instead of going for the 65816 as an upgrade route for the BBC/Master series.

D

[dominicbeesley]

I've not completely given up on this, just been busy tracking down a few bugs. I've made a start on putting Graham's suggested changes into the tube code then go sidetracked by a bug that ended up with me re-writing the monitor and including it in the tube client rom.

I'm now leaning towards the idea of moving all the operating system vectors and hardware vectors up out of the first bank into their own bank and relocating the client code to the top of RAM or possibly leaving it in ROM. What it will do is place some phoney OS vectors in low RAM when running 6502 code.

I've been tweaking BASIC with two aims, 1) make it faster using the new instructions, 2) Make it fit back into a 16k ROM.

2) is fairly easy there's a number of ways to save the off byte here and there using the new 16 bit instructions
1) is more difficult, I've got some things about 25% faster but not much.

One area that would benefit from the new instructions is floating point but unfortunately the mantissa is stored big-endian meaning that most of the 16bit goodness can't be used.

I wonder, how many BASIC programs would have been broken by having the FP numbers stored differently internally?

D