Troubles running Tiny Basic on KIM-1

philippe_elie · Post by **philippe_elie** » Sun Nov 06, 2011 10:38 am

Hello,

I have a KIM-1 equipped with a 4K RAM expansion and an I/O board providing in particular a RS232 socket (both boards were ordered from Bob Applegate, this is a nice piece of work by the way). Everything works fine, I managed to load/save/run several programs via Teraterm running on a W7 PC.

However, I have been unsuccessfully trying to run Tiny Basic, which is supposed to run on a 4K KIM (I saw it uses only 3K). Here is what I did so far :
- get the paper tape format file from the IttyBitty site : this file consists in three chunks of data (starting from 2000, 0100 and 0115 resp) so I used KIMPAPER and KIMTAPE to load them on the KIM. I verified the data was appropriately loaded, but got nothing
- I realized the 4K RAM is actually mapped up to 13FF so I assumed the above binary data was relocatable - which I'm not sure - and loaded the 2000 part to 0200. Nothing again
- I got a disassembled code with the above code from the same site but itis not designed for the KIM and the IO locations are different

Needless to say I spent a significant amount of time googling but could not find anything helpful.

Any advice, help or tricks to make TB work on my shiny new KIM would be greatly appreciated !

Thanks in advance

Philippe

BigEd · Post by **BigEd** » Sun Nov 06, 2011 12:41 pm

Hi Philippe

I'll have a quick look, but others with more direct experience may soon overtake me.

The paper tape image is on this site and as you say, it loads mostly to $2000 with a couple of short sections to page 1.

I ran a cheap disassembly, and see that the code starts with

Code: Select all

2000 4C8520    jmp 2085
2003 4CBD20    jmp 20BD
2006 4C0620    jmp 2006
2009 4C0920    jmp 2009

so it will certainly need to be loaded at that address, or rather intrusively and delicately relocated.

But, you say you verified that it loaded - does that mean you do indeed have RAM at 2000?

Cheers
Ed

philippe_elie · Post by **philippe_elie** » Sun Nov 06, 2011 1:40 pm

thanks Ed for the quick reply.

I'm afraid my explanations were a bit confused. I do not have RAM above 2000, so I actually checked everything loaded OK after I relocated the data from 200.
You're right, I think my first task is to find a disassembler and check the absolute addresses to be modified by hand. It is clear, as you state, it cannot work without proper relocation work.

Cheers
Philippe

BigEd · Post by **BigEd** » Sun Nov 06, 2011 2:29 pm

It looks like the third and fourth JMPs are intended to be vectors for read and write.

So, if you start from that TB.asm file, and just adjust the corresponding code to use the KIM vectors (is that 1E5A and 1EA0?), perhaps you'll be OK? Obviously, also adjust the ORG statement, and be aware of the entry point.

Cheers
Ed

philippe_elie · Post by **philippe_elie** » Sun Nov 06, 2011 3:56 pm

Just tried that, you're spot on, but no more luck, I guess there are other absolute references elsewhere to be patched.... I'm currently searching the web for a disassembler...

BigEd · Post by **BigEd** » Sun Nov 06, 2011 4:10 pm

I was thinking you pretty much need to assemble, starting from that TB.asm - are you thinking the same? (Which is to say, there should be no advantage in disassembly, and no advantage from that tape file.)

I am poking through a naive disassembly but I'm not sure what I'm expecting to learn! (Which is to say, I'm on a diversion, trying to get that basic to run in an emulator with lots of memory.)

(I use the '-d' feature of lib6502 which can dump a memory image with a disassembly. Ruud wrote a disassembler which is much more sophisticated but when I tried it I could not convince it to cover blocks which it had deemed unreachable.)

Cheers
Ed

Using linux (or cygwin) utilities:

Code: Select all

sed 's/.......//;s/.....$//' TBtape.KIM > TBtape.hex
xxd -r -p < TBtape.hex  > TBtape.bin
run6502 -l 2000 TBtape.bin  -d 2000 28ff -x > TBtape.dis.txt

BigEd · Post by **BigEd** » Mon Nov 07, 2011 4:25 pm

I've learnt a couple more tiny facts from Bill O'Neill's reconstructed source:

- you can't relocate by just changing ORG, because there's a table of byte-reversed addresses which isn't (presently) symbolic. The second address is given as $6415 which is byte-reversed $1564, corresponding to label LBL027 in Bill's code. One could probably do some arithmetic based on that to replace the constants with expressions.
- the cold start begins by scanning RAM to find the top. It's a non-destructive scan, but when it scans over a RAM-loaded TinyBasic it might just break itself.

The paper tape version, as we know, is set to load at $2000. It starts scanning RAM at $2900 - this seems like a good idea, to load at the bottom of RAM (in your case $0200, but place user code above TinyBasic. To do this, you need to change the second LDA in the cold start code, to load the right page.

I haven't yet got TinyBasic running in run6502.

Cheers
Ed

philippe_elie · Post by **philippe_elie** » Mon Nov 07, 2011 4:56 pm

Hi Ed,
thanks for your precious advice. I'm about to download lib6502 on my linux laptop, I will try to get the disassembled code alongside with the hex so that I can replace the absolute addresses in the table by labels, I guess since can be done with the disassembler.

Cheers
Philippe

BigEd · Post by **BigEd** » Mon Nov 07, 2011 5:18 pm

I should warn you, if you didn't already notice: the simple-minded disassembly from lib6502 is informative, but not suitable for re-assembly.

Fixing up Bill's source seems like the best hope to me, because patching the paper tape binary would be a lot more work. But investigating the binary, and investigating differences between that binary and a binary from Bill could tell us something - in fact it's already helped a bit.

Cheers
Ed

philippe_elie · Post by **philippe_elie** » Mon Nov 07, 2011 6:23 pm

I came to the same conclusion... after reading the helpful comments that Bill put in his source... and the errors I'm facing compiling run6502 on my laptop....this is the journey that matters, not the destination, !

Cheers
Philippe

BigEd · Post by **BigEd** » Mon Nov 07, 2011 7:55 pm

I'm surprised to hear you have trouble compiling run6502 - it's always been OK for me. Let me know if there's anything I can do.

Well, I've made a little more progress. I can now run Bill's tinybasic on run6502:

Code: Select all

$ perl -p -e '$|++;$_=~s/\n/\r/' | ./run6502 -l 0 tinybasic.1400.65b -G 1406 -P 1409 -R 1400

PRINT 22000/7
?:?
?3142

Those ? characters are features - control codes sent by tinybasic.

The cryptic perl is needed because linux sends \n for newlines but tinybasic likes to see \r carriage returns. There might be a better way to sort that out.

The options to run6502 set up the read and write hooks and the reset vector.

I did make a couple of changes to Bill's code. I had to adjust it place the user area after tinybasic, and to defang the memory test which would run forever:

Code: Select all

  COLD_S   lda #$00                   ; Load accumulator with $00
           sta $20                    ; Store $00 in $20
           sta $22                    ; Store $00 in $22
! ;        lda #$02                   ; Load accumulator with $02
!          lda #$30                   ; Load accumulator with page of user RAM

Code: Select all

  ; Begin test for free ram
  ;
           ldy #$01                   ; Load register Y with $01
! 
! ; fake out the top of memory to a constant
!          lda #$40
!          sta $23 
! 
! MEM_T    LDA (C_22),Y               ; Load accumulator With the contents of a byte of memory
           tax                        ; Save it to X
           eor #$FF                   ; Next 4 instuctions test to see if this memeory location
           sta (C_22),Y               ; is ram by trying to write something new to it - new value
           cmp (C_22),Y               ; gets created by XORing the old value with $FF - store the
! ; patch out first of four bytes to defang the memory test
! ;         php                        ; result of the test on the stack to look at later
           txa                        ; Retrieve the old memory value
           sta (C_22),Y               ; Put it back where it came from
           inc $22                    ; Increment $22 (for next memory location)
           bne SKP_PI                 ; Goto $14A6 if we don't need to increment page
           inc $23                    ; Increment $23 (for next memory page)
! ; patch out three more  bytes to defang the memory test
! SKP_PI
! ;         PLP                        ; Now look at the result of the memory test
! ;         beq MEM_T                  ; Go test the next mempry location if the last one was ram
! 
!          DEY                        ; If last memory location did not test as ram, decrement Y (should be $00 now)
           cld                        ; Make sure we're not in decimal mode

By adding and removing 4 bytes I've kept the length the same, which means no other adjustments.

Cheers Ed

BigEd · Post by **BigEd** » Mon Nov 07, 2011 7:59 pm

(I will probably stop there: I know you still need to relocate the code - I won't try to do that, as it might duplicate your efforts.)

philippe_elie · Post by **philippe_elie** » Mon Nov 07, 2011 10:01 pm

A BIG thank you Ed for your kind support ! The ball is in my hands now ! I already started to tweak Bill's source under the 6502 simulator, ah it's cool, it reminds me my projects from 30 years back

I will keep you posted of my progress...

Cheers and good evening

Philippe

BillO · Post by **BillO** » Fri Nov 11, 2011 11:32 pm

Sorry folks, been away for a while.

I have a newer version of the code that is fully relocatable and all fixed up. It assembles on MK's emulator. Let m e know if you want it and PM an email address.

I should send it to Tom too, to update his site.

philippe_elie · Post by **philippe_elie** » Sat Nov 12, 2011 7:26 am

Hi Bill,
yes that would be great, I will PM you my mail address. I made some progress though and will continue working on this anyhow as this is a good way to get me back to speed...
cheers
Philippe