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.gordonDrogon wrote: ↑Thu Feb 22, 2024 7:48 pm 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...
Porting BASIC2 to a homebrew system
Re: Porting BASIC2 to a homebrew system
Re: Porting BASIC2 to a homebrew system
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..gordonDrogon wrote: ↑Thu Feb 22, 2024 7:48 pm Basic polls $FF. when the top-bit is set then Escape has been pressed.
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..
Re: Porting BASIC2 to a homebrew system
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.SparkyNZ wrote: ↑Thu Feb 22, 2024 7:40 pmThat 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!gordonDrogon wrote: ↑Thu Feb 22, 2024 7:24 pm Basic polls $FF. when the top-bit is set then Escape has been pressed.
- Rich Talbot-Watkins
- Posts: 2054
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: Porting BASIC2 to a homebrew system
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
- Posts: 94
- Joined: Fri Nov 23, 2018 12:39 pm
- Location: Scottish Borders
- Contact:
Re: Porting BASIC2 to a homebrew system
The keycode (ESC) is inserted into the keyboard input buffer - then OSRDCH reads it as part of OSWORD 0 and "oh look, Escape" ...Rich Talbot-Watkins wrote: ↑Fri Feb 23, 2024 11:11 amWhat 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.
So you need to make sure buffers are flushed too.
-Gordon
Re: Porting BASIC2 to a homebrew system
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.
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.
Re: Porting BASIC2 to a homebrew system
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).
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.
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.
Code: Select all
10 PRINT 6
20 CLS
30 GOTO 10
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
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.
Re: Porting BASIC2 to a homebrew system
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).
So above, we have 3 bytes of tokenized output, then we add 3 and that's the 06 length.. or..
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!
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 ^
Code: Select all
00 1e 0b 20 e5 20 8d 54 4a 40 0d // 30 GOTO 10
^ 8 ^
Seems pretty straighforward now.. but didn't for the last hour or so!
Re: Porting BASIC2 to a homebrew system
Looking at the BASIC 2 disassembly.. (and the BBC Compendium book, page 267)..
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
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"?
Code: Select all
; If the first character is not a token for a statement, enter the assignment routine
8BAD:cmp #&CF
8BAF:bcc &8BBF
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"?
Re: Porting BASIC2 to a homebrew system
Pseudo-variables such as TIME and HIMEM actually have two tokens, depending whether they appear on the left or right side of an assignment.
Re: Porting BASIC2 to a homebrew system
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.
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.
Re: Porting BASIC2 to a homebrew system
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:
or equivalently:
or equivalently:
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.
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)
Code: Select all
LDA #LO(NOT(&C0))
LDX #LO(-8)
Code: Select all
LDA #NOT(&C0) AND &FF
LDX #-8 AND &FF
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.
Re: Porting BASIC2 to a homebrew system
Thank you I've gone with those examples and everything still assembles the same.Steve wroteCode: Select all
LDA #NOT(&C0) AND &FF LDX #-8 AND &FF
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
- Attachments
-
- AcornCmosBasic-Beebasm.zip
- Acorn Cmos Basic source in Beebasm format
- (43.54 KiB) Downloaded 1 time