BBC Basic 4 vs 3 ...

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
User avatar
gordonDrogon
Posts: 20
Joined: Fri Nov 23, 2018 12:39 pm
Location: Devon
Contact:

BBC Basic 4 vs 3 ...

Post by gordonDrogon » Sat Apr 27, 2019 6:52 pm

I have some non-Acorn hardware that has a WDC 65C02 and 64K of RAM. It runs BBC Basic 3 as well as it can, given the systems limitations. However... When I load up BBC Basic 4, it appears to run, and, indeed, most programs I've entered - e.g. the text Mandelbrot program run just fine.

One thing doesn't work and I can't as yet, see why is the INPUT statement. This works fine in Basic 3, but not in Basic 4. In Basic 4, it prints the ? prompt, accepts the line of text, then ... nothing. It hangs.I don't have a logic analyser to see what's going on - I have a 'scope, but before I start to dig-in, bit at a time, I am wondering if anyone may have any insight to this.

Obviously I can stick to Basic 3, but 4 is faster - presumably taking advantage of the 65C02 instructions and a years more development, etc.

I have hooks into all the MOS vectors, so anything I don't currently handle is printed to screen so I can see what goes on - nothing comes out with Basic 4. My thoughts are that it's doing something undocumented, or maybe running an "illegal" instruction that worked in the early 65C02's but not the WDC 65C02?

Anyway, if anyone had any insight, I'd appreciate it.

Thanks,

-Gordon

cmorley
Posts: 936
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: BBC Basic 4 vs 3 ...

Post by cmorley » Sat Apr 27, 2019 7:07 pm

It isn't a WDC processor problem.

I built a co-pro using the WDC part and HiBASIC 4 and 4.3 both work fine it seems. I just tried INPUT A$ and it works as expected...

jimmy
Posts: 100
Joined: Tue May 06, 2008 6:37 pm
Contact:

Re: BBC Basic 4 vs 3 ...

Post by jimmy » Sun Apr 28, 2019 7:55 am

I'd always use BASIC 4 over BASIC 3 - it's much faster, and I like the "LIST IF" feature.
Have you seen the BBC BASIC IV disassembly PDF by Christopher Dewhurst and Steve Fewell? Very useful!
INPUT in BASIC4 is at &B8B6.
Check the value of Accumulator and Carry Flag on exit from OSWORD 0. The Carry Flag should be clear unless you really did press ESCAPE.
Also check that any call to the ECONET vector isn't causing any problems.

User avatar
gordonDrogon
Posts: 20
Joined: Fri Nov 23, 2018 12:39 pm
Location: Devon
Contact:

Re: BBC Basic 4 vs 3 ...

Post by gordonDrogon » Sun Apr 28, 2019 9:10 am

Thanks for the replys.

Good to know that it's not the WDC processor though.

I'm running the ROM image that JGH has on his mdfs.net site. This is the one assembled at &8000. Not sure I can fit HiBasic into my system.

I also took the source on his site and have made an attempt to translate it into ca65 format rather than BBC Basic format, however while it assembles, there are a couple of "off by one" errors somewhere that I'll need to spend time to get to the bottom of, but for now it's not that important.

I think osword 0 is working fine though - everything else seems OK with it - my own command-line OS, Basic3/4 at the command level, BCPL.. There is no escape detection yet though. My return from osword0 is:

Code: Select all

        jsr     osNewl
        ldy     aLen            ; Return length
        clc                     ; Carry clear - No escape condition
        rts
Acc would have &0D left over from the call to osNewl... No mention of what A needs in my advanced user guide, however I'm finding some of the (filing system) calls expect more than the book says, so maybe there's something there and I might have to go and check some of the published MOS disassemblys...

The Econet vector? Hm. If anything decides to redirect via that, (as with all other un-implemented vectors in my system), it is supposed to print a message on the console and abort the application/rom and return to the OS command-line - that doesn't appear to happen, so I presume nothing goes via it. (Certainly I've not written anything to use it - my "MOS" is written from scratch, the only unknown code really is the Basic ROM image here..

I'll live with Basic3 for now, but will comeback to this when I have time.

Cheers,

-Gordon

User avatar
gordonDrogon
Posts: 20
Joined: Fri Nov 23, 2018 12:39 pm
Location: Devon
Contact:

Re: BBC Basic 4 vs 3 ...

Post by gordonDrogon » Sun Apr 28, 2019 5:05 pm

Well - decided to give this more thought this afternoon and had a closer look through the disassembly on the mdfs.net site...

And solved it.

Turns out, as well as the carry being clear, A has to be ZERO on return - my osWord 0 routine left it set to &0D. Basic3 and BCPL didn't seem to care - neither did Basic4 until the INPUT command when it did seem to care.

I've no idea what Basic4 is doing when it gets the input - I can see from the 2 memory bank status LEDs I have on the board (A15 and not A15 for 2 x 32KB banks of RAM) that it's running code from the top 32K and accessing data in the bottom 32K - I suspect it's stuck in a loop somewhere. It's most odd, but it's sorted now, and my little sieve benchmark now runs in 6.5 seconds (Basic4), was 7.5 (Basic3). (and BCPL is 3.3 :-)

Thanks,

-Gordon

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

Re: BBC Basic 4 vs 3 ...

Post by jgharston » Sun Apr 28, 2019 10:04 pm

The core bit is here in Basic 4:
JSR LBA70 :\ Read line of text
....
.LB91F
STA &1B
STZ &19

and
\ Input string to string buffer
\ -----------------------------
.LBA70
....
TYA:JSR OSWORD :\ Call OSWORD 0
BCC LBA95 :\ CC, Escape not pressed
JMP errEscape :\ Escape
.LBA92
JSR OSNEWL
.LBA95
STZ &1E:RTS :\ Set COUNT to zero and return


whereas before, the code at LBA92 was:
.LBC25
JSR OSNEWL
.LBC28
LDA #&00:STA &1E :\ Set COUNT to zero
RTS

The INPUT code is calling the call-OSWORD-0 code, and relying on that code to return A=0 when it uses it to set &1B. &19/&1A/&1B is a next-thing-to-process prointer. However, by optimising the LDA #0:STA to STZ, that code no longer forces A to be zero, so code that calls the call-OSWORD-0 code is now relying on OSWORD 0 to return 0.

A rule of thumb I've always followed when implementing service routines is that anything that is not specified to return anything is returned preserved. eg OSFILE tells you what's in A but says nothing about X and Y, so I ensure X and Y are preserved. And, as a caller, if the documentation doesn't say anything about a register I assume it is entirely trashed and unusable.

Interestingly, the MOS does not ensure A=0 on exit from OSWORD 0. A will hold the escape flag at &FF rotated left. Normally, &FF toggles between &00 and &FF, so on exit from OSWORD 0 A will be &00 or &FF, but only bit 7 of &FF indicates an escape state, it is possible to set &FF to &0F indicating 'no escape state', but OSWORD &FF will then return &1E. I think the Internationalisation ROM does use the bottom bits of &FF as transient workspace.

Code: Select all

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

User avatar
gordonDrogon
Posts: 20
Joined: Fri Nov 23, 2018 12:39 pm
Location: Devon
Contact:

Re: BBC Basic 4 vs 3 ...

Post by gordonDrogon » Mon Apr 29, 2019 7:44 am

Thanks for the feedback. I think because Basic4 has squeezed more bits & speed into it, while using 65C02 instructions, I suspect it's also made more assumptions about the MOS too to keep it inside its 16K ROM limitation.

Other things I've found not BASIC related, but BCPL is it's use of osGbpb - I found it was failing until I updated the number of bytes to transfer in the parameter block to the actual number of bytes transferred (ie. zero - anything else isn't re-tried, but considered an error). Nothing in the documentation to indicate this - however my documentation is the Advanced User Guide - I don't have any "how to write a filing system for the Beeb" documentation - if there actually is any?

I might try the Pascal ROM next. I did try View and it seemed to work except screen/cursor moving, but I've "fixed" that now, although using a serial terminal to a "Beeb" is somewhat challenging - e.g. the BCPL editor assumes that if you move the cursor up when on the top line, the screen will scroll down. ANSI terminals don't.

I'm sure I'll run in to some more "gotchas" like that - one system call at a time...

If anyone's interested in my project, I've put a lot of ramblings here: https://projects.drogon.net/6502-ruby/ and will bring it along to Cambridge at the end of June. (The blog is somewhat behind the hardware though - it's currently on a PCB rather than stripboard)

Cheers,

-Gordon

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

Re: BBC Basic 4 vs 3 ...

Post by jgharston » Mon Apr 29, 2019 9:13 am

gordonDrogon wrote:
Mon Apr 29, 2019 7:44 am
however my documentation is the Advanced User Guide - I don't have any "how to write a filing system for the Beeb" documentation - if there actually is any?
Advanced User Guide, page 342:
"If a transfer has not been completed the number of bytes or names which have not been transferred are written to the parameter block in the ‘number of bytes to transfer’ field."

I suppose that's slightly ambiguous, what happens when the transfer is successful? However, I've always read that as meaning that if the transfer is successful, the 'number of bytes' field is updated to indicate that zero bytes have not been transfered. That is, the 'number of bytes' field is *always* updated. Otherwise, there would be no way to tell apart 'n bytes have been transfered successfully' and 'n bytes have not been transfered'. And there's fewer exceptions if the returned value is always updated. If in doubt, the fewer special cases the better.
gordonDrogon wrote:
Mon Apr 29, 2019 7:44 am
the BCPL editor assumes that if you move the cursor up when on the top line, the screen will scroll down. ANSI terminals don't.
Some ANSI terminals don't.
Last edited by jgharston on Mon Apr 29, 2019 9:15 am, edited 1 time in total.

Code: Select all

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

User avatar
gordonDrogon
Posts: 20
Joined: Fri Nov 23, 2018 12:39 pm
Location: Devon
Contact:

Re: BBC Basic 4 vs 3 ...

Post by gordonDrogon » Mon Apr 29, 2019 10:04 am

jgharston wrote:
Mon Apr 29, 2019 9:13 am
gordonDrogon wrote:
Mon Apr 29, 2019 7:44 am
however my documentation is the Advanced User Guide - I don't have any "how to write a filing system for the Beeb" documentation - if there actually is any?
Advanced User Guide, page 342:
"If a transfer has not been completed the number of bytes or names which have not been transferred are written to the parameter block in the ‘number of bytes to transfer’ field."

I suppose that's slightly ambiguous, what happens when the transfer is successful? However, I've always read that as meaning that if the transfer is successful, the 'number of bytes' field is updated to indicate that zero bytes have not been transfered. That is, the 'number of bytes' field is *always* updated. Otherwise, there would be no way to tell apart 'n bytes have been transfered successfully' and 'n bytes have not been transfered'. And there's fewer exceptions if the returned value is always updated. If in doubt, the fewer special cases the better.
Ah yes, but I took that to be part of the "a=8; read filenames" option, so plenty of scope to be ambiguous there..
gordonDrogon wrote:
Mon Apr 29, 2019 7:44 am
the BCPL editor assumes that if you move the cursor up when on the top line, the screen will scroll down. ANSI terminals don't.
Some ANSI terminals don't.
[/quote]

Another source of ambiguity. Ah well, live and learn.

An option I did look at was to write my own "terminal" - essentially an SDL application running under Linux (I'm currently just running minicom in an xterm) I already have 95% of what's needed there as part of another project (my RTB Basic) so it might not be hard, and I have toyed with passing the graphics (and sound) primitives over the serial link too - more proof of concept than actually anything usable, but who knows. Franken-beeb if ever there was one!!!

Cheers,

-Gordon

User avatar
Richard Russell
Posts: 877
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: BBC Basic 4 vs 3 ...

Post by Richard Russell » Mon Apr 29, 2019 11:22 am

gordonDrogon wrote:
Mon Apr 29, 2019 10:04 am
An option I did look at was to write my own "terminal" - essentially an SDL application running under Linux
Both BBC BASIC for SDL 2.0 and Matrix Brandy BASIC (the former using SDL 2.0 and the latter SDL 1.2) contain, effectively, a 'terminal' driven by VDU codes which are more-or-less compatible with the Acorn equivalents in 6502 MOS and ARM RISC OS. Either could probably be 'separated out' to form the core of a standalone terminal of the kind you describe.

In the case of BBCSDL, which of course I know most about, the relevant module is bbcvdu.c which is not too intwined with the rest of BBC BASIC; it works with a customised version of SDL2_gfx to provide the 2D graphics and bbcvtx.c for the MODE 7 (teletext) emulation plus flood.c for the flood-fill primitives.
Last edited by Richard Russell on Mon Apr 29, 2019 11:37 am, edited 1 time in total.

User avatar
gordonDrogon
Posts: 20
Joined: Fri Nov 23, 2018 12:39 pm
Location: Devon
Contact:

Re: BBC Basic 4 vs 3 ...

Post by gordonDrogon » Mon Apr 29, 2019 1:57 pm

Richard Russell wrote:
Mon Apr 29, 2019 11:22 am
gordonDrogon wrote:
Mon Apr 29, 2019 10:04 am
An option I did look at was to write my own "terminal" - essentially an SDL application running under Linux
Both BBC BASIC for SDL 2.0 and Matrix Brandy BASIC (the former using SDL 2.0 and the latter SDL 1.2) contain, effectively, a 'terminal' driven by VDU codes which are more-or-less compatible with the Acorn equivalents in 6502 MOS and ARM RISC OS. Either could probably be 'separated out' to form the core of a standalone terminal of the kind you describe.

In the case of BBCSDL, which of course I know most about, the relevant module is bbcvdu.c which is not too intwined with the rest of BBC BASIC; it works with a customised version of SDL2_gfx to provide the 2D graphics and bbcvtx.c for the MODE 7 (teletext) emulation plus flood.c for the flood-fill primitives.
Hi Richard,

Thanks for this, but with the exception of "mode 7" (which I'm not that fussy about) I have all this already in RTB - which is where I was going to cull the code from. I'm just torn between the effort of writing a "terminal" (which to be honest I could write in RTB Basic!) or put the effort into a "graphics card" for my next-generation Ruby board which I'm in the middle of finalising the PCB layout for.

However the "graphics card" is a 32-bit ARM chip on a $5 SBC with an HDMI output which will be running a variant of RTB that pokes pixels in "bare metal" mode rather than use SDL under Linux, so since that's going to be 90% of the same code then maybe I will.

It's just a fun little project after all... It became BBC Micro-ish more by accident than design.

-Gordon

User avatar
Richard Russell
Posts: 877
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: BBC Basic 4 vs 3 ...

Post by Richard Russell » Mon Apr 29, 2019 3:06 pm

gordonDrogon wrote:
Mon Apr 29, 2019 1:57 pm
which to be honest I could write in RTB Basic!
Indeed, as it could equally be in BBC BASIC (using BBCSDL or Brandy), which I might argue would be more appropriate! :lol: But either way the 'VDU stream' interface is ideally suited to separating the 'terminal' into a remote box. I wish Acorn had stuck with it in BASIC 5 (some graphics statements bypass the VDU stream) but that's off-topic and has been discussed before.

Post Reply