Porting BASIC2 to a homebrew system

[SparkyNZ]

Also stuff from JGHs site... He had a page on the bare -minimum needed to get Basic going and I just started to trace and track all the osbyte/words being called as it ran and wrote the code as needed...

Yeah I've been in touch with JGH - that "porting" link was broken so I think the page with the bare minimum is missing/lost at the moment. We'll get there.

[SparkyNZ]

Basic polls $FF. when the top-bit is set then Escape has been pressed.

Just realised what the problem was - I wasn't clearing the $FF MSB when OSBYTE=&7e was called. Program is now escaping properly Back to work I must go.. Ugh..

And just in case anybody ever wondered what BBC BASIC may have looked like on a Vic 20..


At the moment I'm entered commands in a windows text edit field so you won't see them on the screen. No, I don't have any intention of putting BBC BASIC on a Vic 20. I just re-used my Vic emulator and thought it looked funny I'll be work on my screen editor next.. and jumping to 80x60 text instead of the amazing 22x23 of the Vic screen I do need to sort out upper/lowercase output too but that's just a hangover from the Vic emulator.

Hmm. Looks like I am processing Esc twice - once to stop the program and also sending it on the command line. I wonder how I'll distinguish between those 2 cases..

[paulb]

Basic polls $FF. when the top-bit is set then Escape has been pressed.

That sounds easy enough. Any idea where this is documented in the 4 manuals? I'll give this a try right now before I get too busy!

Page 187 in chapter 12 ("Memory allocation and usage") in the Electron AUG. There are various places where the behaviour of Escape is configured in the MOS, but I doubt that supporting them will be a priority.

[Rich Talbot-Watkins]

Hmm. Looks like I am processing Esc twice - once to stop the program and also sending it on the command line. I wonder how I'll distinguish between those 2 cases..

What happens if you press and hold Escape? Do you get repeated Escape conditions processed by BASIC? This is just a roundabout way of pointing out that the BBC OS doesn't expect Escape to auto-repeat.

I can't think of another reason why it would be getting processed twice. In theory, when BASIC detects the escape condition (by polling bit 7 of $FF) it should then acknowledge it immediately (calling OSBYTE 126 to clear bit 7), and nothing should then be setting it again until Escape is released and pressed again.

[gordonDrogon]

Hmm. Looks like I am processing Esc twice - once to stop the program and also sending it on the command line. I wonder how I'll distinguish between those 2 cases..

What happens if you press and hold Escape? Do you get repeated Escape conditions processed by BASIC? This is just a roundabout way of pointing out that the BBC OS doesn't expect Escape to auto-repeat.

I can't think of another reason why it would be getting processed twice. In theory, when BASIC detects the escape condition (by polling bit 7 of $FF) it should then acknowledge it immediately (calling OSBYTE 126 to clear bit 7), and nothing should then be setting it again until Escape is released and pressed again.

The keycode (ESC) is inserted into the keyboard input buffer - then OSRDCH reads it as part of OSWORD 0 and "oh look, Escape" ...

So you need to make sure buffers are flushed too.

-Gordon

[SparkyNZ]

That was a bug and my own fault. I was setting MSB of $FF as well as populating the input buffer at $700. I think I should have only been populating $700 when blocking in the OSWORD=&00 call.

It's behaving perfectly now

I'm having a bit of a break from BASIC itself now - paying more attention to the screen editor so I can match what I expect on my real hardware. Once I have that working I'll be able to flex the BASIC muscles a bit and find out what else I'm missing.

[SparkyNZ]

Can somebody please help me understand the tokenised line format, please? (or point me to a relevant page in one of the common BBC ref books).

Code: Select all

   10 PRINT 6
   20 CLS
   30 GOTO 10

I grabbed the bellow hex dump from memory. I've tried working my way through it - but there are some parts I cannot figure out.

Code: Select all

0d 00 0a 08 20 f1 20 36 0d 00 14 06 20 db 0d 00 1e 0b 20 e5 20 8d 54 4a 40 0d ff

// Breakdown..
0d 
00 0a 08  // 10

20 f1 20 36 0d   // PRINT 6

00 14 06  // 20

20 db 0d  // CLS

00 1e 0b  // 30

20 e5 20 8d 54 4a 40 0d  // GOTO 10

ff

I'm assuming line numbers are in MSB, LSB format (e.g. 00 0a for line 10, 00 14 for line 20) but what is the 3rd byte that follows the line number? It looks like a length of some sort, but I cannot figure out what it represents.

As for the GOTO, I guess it's followed by token 8D which is a line number, with the following 3 bytes described here: http://www.benryves.com/bin/bbcbasic/ma ... eniser.htm (or here: https://mdfs.net/Docs/Comp/BBCBasic/LineFormat)

..problem is that neither of these links describe how the length byte works.

[SparkyNZ]

I've been looking at the C tokeniser code presented here: viewtopic.php?t=16476

Memory[LengthAddr] = (Uint8)(Addr - LengthAddr + 3);

So.. looking at this code, the length is always the length of the generated/tokenized output with 3 added to it (for the MSB/LSB and length byte).

Code: Select all

00 14 06  20 db 0d  // 20 CLS
          ^ 3    ^

So above, we have 3 bytes of tokenized output, then we add 3 and that's the 06 length.. or..

Code: Select all

00 1e 0b  20 e5 20 8d 54 4a 40 0d  // 30 GOTO 10
          ^ 8                  ^

Here there are 8 bytes that follow the length, so we add 3 and that becomes the $0B

Seems pretty straighforward now.. but didn't for the last hour or so!

[SparkyNZ]

Looking at the BASIC 2 disassembly.. (and the BBC Compendium book, page 267)..

Code: Select all

; If  the  first  character  is  not  a  token  for  a  statement,  enter  the  assignment  routine 
8BAD:cmp  #&CF 
8BAF:bcc  &8BBF 

I used the below online 6502 emulator to quickly test some results of different accumulator tests against $CF:
https://www.cs.otago.ac.nz/cosc243/reso ... onsts.html

Code: Select all

;lda #$db  ; Carry is 1
;lda #$02  ; Carry is 0
;lda #$8e  ; Carry is 0
;lda #$c8  ; Carry is 0
;lda #$ce  ; Carry is 0
;lda #$cf  ; Carry is 1
lda #$d0  ; Carry is 1
cmp #$cf

What is the the cmp #$Cf actually doing?? Tokens start from $8E (or thereabouts).

This piece of code seems to set the carry if a token of $cf or greater is used.

What is the significance of the tokens from $cf and above? I thought I'd read (somewhere??) that tokens are grouped according to procedural vs functional use (ie. return value vs no return value). Am I on the right track? .. and whereabouts did I read that..

UPDATE: I have found this: https://mdfs.net/Docs/Comp/BBCBasic/Tokens

Looking at that, it would seem like operators and functions are tokens lower than $CF ($80 thru C$CE) and $CF and above are "commands"?

[julie_m]

Pseudo-variables such as TIME and HIMEM actually have two tokens, depending whether they appear on the left or right side of an assignment.

[PeterC]

Hello,

As an exercise, I just converted the AcornCMOSBasic source in the Stardot Github repository to beebasm format.

I used Coeus's Perl Script https://www.stardot.org.uk/forums/viewt ... rl#p354359 as starting point, followed by brute force and ignorance.

I created and then extracted a fresh assemble of the Basic ROM binary from a DFS disc image using Beebem.

I have managed to get the source to assemble to a point where FC/B from a Windows command prompt cannot detect any differences.

There were two types of MASM source occurrence I could not convert and currently am just defining the resultant bytes, so was wondering if someone could help with their conversion and provide beebasm equivalents to the following two examples:

LDAIM :NOT: &C0
LDXIM -8

Lastly I would like to check my following assumptions:
1. I cannot have labels that represent special words in beebasm, so I have to replace FALSE,TRUE and PI with something like FALSESYM, TRUESYM and PISYM in the source.
2. The original ASSERT statement:
ASSERT :MSB: SIGHT = :MSB: .
becomes:
ASSERT HI(SIGHT) = HI(*)

Thanks for any advice offered.

[SteveF]

Hi Peter,

I'm not that familiar with MASM but I can guess what the problem is here. I suspect your two examples would be written in beebasm as:

Code: Select all

LDA #<NOT(&C0)
LDX #<(-8)

or equivalently:

Code: Select all

LDA #LO(NOT(&C0))
LDX #LO(-8)

or equivalently:

Code: Select all

LDA #NOT(&C0) AND &FF
LDX #-8 AND &FF

The problem is that both -8 and NOT(&C0) when viewed as (let's say) 32-bit binary values internally by beebasm have bits set beyond the bottom 8, so they aren't valid 8-bit constants. In beebasm you have to explicitly truncate them (it's a bit like a cast from a larger to smaller integer type in C) to make them fit in a byte to show that you want the higher bits to be discarded.

Your assumptions seem reasonable to me, but as I say I'm not that familiar with MASM. You could potentially use lower case labels if that would help disambiguate things (so use "true" in the BASIC source to distinguish it from beebasm's "TRUE" constant), but your solution is probably better in this case.

[PeterC]

Steve wrote

Code: Select all

LDA #NOT(&C0) AND &FF
LDX #-8 AND &FF

Thank you I've gone with those examples and everything still assembles the same.

I don't know if it will be of use to anyone but I've attached the results of my labours below.

I maintained the separate files to match the original and created an extra link file and called it CBAS00.6502

Peter