MS Basic 4.7c - Intel HEX Uploading - Am9511A APU option

[Phillip Stevens]

Over the last month I've been working on support for the Am9511A APU Module within MS Basic, and now finally it is time to draw a line and call it a Release.

MS BASIC 4.7c - RC2014

Initially, I started with MS Basic support as my APU stretch goal, but working on it turned out to be a worthy goal for RC2014 generally. Over the past weeks I've learned a lot about the workings of the MS Basic code, and I hope to have improved on it in some ways.

As well as providing full support for the APU within MS Basic, I've added a couple of features that make MS Basic much more useful as a tool for modern C and assembly development with the RC2014.

New Keywords - HLOAD & RESET

Previously, the HexLoad tool stood outside MS Basic, which meant that the user had to be aware of correctly setting the Basic Memory Top, and then configuring the jump address for the assembly program linkage within Basic, before the USR(x) function could work correctly. This process was a little complicated, and stood in the way of easy use by new users. But that is no longer the case.

The new integrated HLOAD keyword automatically sets the MS Basic Memory Top to below the Origin of the Intel HEX code being uploaded, and it also enters the first read code location into the USR(x) jump address. This means that uploading Intel HEX within Basic and then running programs compiled with z88dk, or assembled with another tool, is very easy. Compile the code, upload the code with HLOAD, and run the code from command line with ?USR(0) or from within a Basic program. That's the whole process.

I've also added a RESET keyword (or rather changed its unused NASCOM meaning), to enable a programmatic cold start of the RC2014. The RESET keyword is to revert to a "clean" memory state, and to revert the Memory Top settings applied by HLOAD.

Z80 Op Code Optimisation

Further, since the RC2014 is Z80 based, I've tried to optimise the MS Basic code to use Z80 instructions where relevant, and to in-line code to improve the handling of the floating point and string pointer registers. These improvements are visible in a 5% to 6% improvement in the benchmarks (bubble sorting, Mandelbrot, etc) with respect to the original MS Basic. Not much; but certainly worthwhile. It is clear that the Microsoft team wrote very tight code and (by version 4.7) as there is little wastage within MS Basic. Only by changing the programming parameters to include Z80 Op Codes was it possible to make some improvements.

Additionally, the ACIA serial interface is configured with a very large Rx buffer and, taken together with the performance improvements, this makes pasting Basic programs much more reliable.

Uploading Intel HEX to the RC2014 using the HLOAD keyword can be done at line rate 115200 Baud using Unix cat. There's no need to slow the upload using slowprint, so large assembled programs can be uploaded very quickly.

Am9511A APU Support

Turning to the Am9511A APU Module support. Well that's now fully integrated into MS Basic too. All Basic programs will use the APU Module with no added effort.

As MS Basic does all its arithmetic in floating point, I would have thought that having arithmetic offloaded to the APU would make a huge difference. Well actually, it doesn't. It turns out that there is so much overhead in "interpreting" the tokenised byte code of a Basic program as it is running, that having a fast floating point solution makes only very moderate difference to Basic benchmarks. It is only about 10% faster than the standard MS Basic, or 5% faster than the tuned MS Basic for the standard RC2014. Looking at the logic analyser it is easy to see the APU is not called upon sufficiently quickly to keep it busy.

This MS Basic result is quite different from the situation with uploaded programs, where the benchmarks using compiled z88dk C uploaded to the RC2014 plus APU Module vary from worst case 2x soft floating point to best case over 4x soft floating point.

This is not the end of the story, as I intend to go on optimising MS Basic for the APU Module. But at this point in time everything is working well, and so it is time to call it a release.

Supported RC2014 Hardware

The linked files are for a Mini, Micro, or Classic RC2014 with 8kB ROM, 32kB RAM, and the MC68B50 ACIA.

It is possible to support other hardware, but that hardware is better covered by more advanced systems (aka CP/M or RomWBW) than booting to MS Basic.

The NASCOM BASIC 4.7 Repository where everything is located.

Let me know with an issue if you find any problems, or here to just chat.

Enjoy, Phillip

[Phillip Stevens]

Phillip Stevens wrote:

Over the last month I've been working on MS Basic.

MS BASIC 4.7c - RC2014

Initially, I started with MS Basic support as my APU stretch goal, but working on it turned out to be a worthy goal for RC2014 generally. 

Over the past weeks I've learned a lot about the workings of the MS Basic code, and I hope to have improved on it in some ways.

I thought it might be good to note the changes to the original MS Basic 4.7 code, which generate about 8% improvement in the benchmarks (Mandelbrot, Selection Sort, Pi). 

 

Z80 Op Code Optimisation

Further, since the RC2014 is Z80 based, I've tried to optimise the MS Basic code to use Z80 instructions where relevant, and to in-line code to improve the handling of the floating point and string pointer registers.

MS Basic uses 4 Byte values extensively as floating point numbers in Microsoft Basic Format, and as pointers to strings. Many of the improvements are in handling these values as they are shifted around in memory, and to BCDE registers and the stack.

1. 4 LDI instructions are used to move values from one location (the Floating Point Register FPREG) to another in memory, and these are in-lined to also save the call-return cycles.
2. The LD (x),DE LD(x+2),BC instruction pair is used to grab values into registers and save from registers, avoiding the need to preserve HL and often saving push-pop cycles and of course the call-return cycles.
3. There is a 16_16x16 multiply MLDEBC used to calculate table offsets, which was optimised to use shift instructions available to the Z80. I experimented with different zero multiplier checks, and with removing the checks, but Microsoft had already done the right optimisation there, so it was left as it was.
4. The extensions that Grant Searle had inserted into the operand evaluation chain to check for Hex and Binary numbers were moved to the end of the operand checks, so as not to slow down the normal operand or function evaluation.

Doing these changes got about 6% improvement in the benchmarks.

The next step was to use the z88dk-ticks tool to evaluate hotspots and try to remediate them. Recently Dom @suborb added the ability to emulate the Am9511A APU into the tool, and together with the debug mode it is possible to capture exactly how many iterations (visits) and how many cycles are consumed by each instruction.

The testing revealed that the comparison function CPDEHL was a very heavily used function. As it is quite small, and through removing the call-return overhead, it adds only a few bytes per instance to in-line it. There is plenty of space in the 8kB ROM to allow this change so it was made.

Then, the paths taken by the JR and JP conditional instructions were examined, by checking which path was taken most frequently across the benchmarks. This resulted in changing a few JR instructions for JP instructions, when the conditional path was mostly true, and one replacement of a JP instruction where the conditional was most often false.

So with these changes we are now at 8% improvement over the original Microsoft code.

Looking further at z88dk-ticks hotspot results, the next most used function is GETCHR used to collect input from code strings. GETCHR is a larger function and is used about 50 times throughout the code base, so there is little point to in-line it. However I do note the new JR conditional is used in checking for spaces in token strings, which does save a few cycles. Microsoft warns in the Nascom Basic Manual to optimise performance by removing spaces in code. Now it is even more true than before.

So at this point I'll call it done. It seems that without rewriting the code substantially that's about all that I can squeeze out.

The result is that with no change in function, MS Basic is now simply 8% faster.

[rwd...@gmail.com]

Do you have any plans/desire to give updated maths routines (with and without APU support) to BASCOM?

There is an interesting BASIC progam called HP45 (e.g.  HP45-208.LBR) by Loring C. Chien which should benefit from incorporation of faster and more accurate maths routines.

The source code for HP45 is available to rebuild under BASCOM

Richard

[Phillip Stevens]

Do you have any plans/desire to give updated maths routines (with and without APU support) to BASCOM?

I guess you're talking about the Microsoft Basic compiler, BASCOM? I think the short answer is no. There's some reasons for that no, and none of them are related to "desire". I would have a desire to do it, but practically it will be too hard.

Source code. I don't think anyone has the source code for BASCOM 5.3. If anyone does, then let us know. Would be great to dig through it and it would open the possibility to integrate APU code into it.

Performance. BASCOM compiles Basic, and the resulting code is about 3x faster than MBASIC interpreted Basic code. It might be possible to modify the BASCOM libraries (if Source Code were available), and try to do a better job using Z80 instructions or using the APU. The APU would make BASCOM compiled Basic much faster, I would guess.

Optimisation. The MBASIC floating point code, and all the code in general, is excellent. I couldn't find any way to further optimise it. The only way to make it "better" was to change the game, and use Z80 instructions instead of 8080 instructions for some important activities. It would be possible to do the same with the BASCOM libraries, if the source code was available. Otherwise it would be very opaque to fix.

Accuracy. Just a note about accuracy for completeness. I've not changed the MBASIC routines in any way. They're already as fast and accurate as can be. I mean, they've pulled a lot of tricks to get fast, including some conditional execution code which is very neat. All I could do was to simplify the MBF and string pointer handling.

There's an easy way to see the differences now. I've done a delta into the RC2014 directory, which has most of the improvements. Have a look at this commit. Load the diff for bas32k.asm.

There is an interesting BASIC program called HP45 (e.g.  HP45-208.LBR) by Loring C. Chien which should benefit from incorporation of faster and more accurate maths routines.

The source code for HP45 is available to rebuild under BASCOM.

Probably, if you're really interested in performance, it would be easiest to re-write the BASIC code into C code, and then compile it with Z88DK. That would be an effective way to get improvement for both soft and APU floating point.

Cheers, Phillip

 

Phillip Stevens wrote:

Over the last month I've been working on MS Basic.

MS BASIC 4.7c - RC2014

Initially, I started with MS Basic support as my APU stretch goal, but working on it turned out to be a worthy goal for RC2014 generally. 

Over the past weeks I've learned a lot about the workings of the MS Basic code, and I hope to have improved on it in some ways.

I thought it might be good to note the changes to the original MS Basic 4.7 code, which generate about 8% improvement in the benchmarks (Mandelbrot, Selection Sort, Pi). 

 

Z80 Op Code Optimisation

Further, since the RC2014 is Z80 based, I've tried to optimise the MS Basic code to use Z80 instructions where relevant, and to in-line code to improve the handling of the floating point and string pointer registers.

[Phillip Stevens]

Do you have any plans/desire to give updated maths routines (with and without APU support) to BASCOM?

I guess you're talking about the Microsoft Basic compiler, BASCOM? I think the short answer is no. There's some reasons for that no, and none of them are related to "desire". I would have a desire to do it, but practically it will be too hard.

Source code. I don't think anyone has the source code for BASCOM 5.3. If anyone does, then let us know. Would be great to dig through it and it would open the possibility to integrate APU code into it.

Would be great to get the library source code... if it is around somewhere.

 

Performance. BASCOM compiles Basic, and the resulting code is about 3x faster than MBASIC interpreted Basic code. It might be possible to modify the BASCOM libraries (if Source Code were available), and try to do a better job using Z80 instructions or using the APU. The APU would make BASCOM compiled Basic much faster, I would guess.

Just checking that the assertion on wikipedia that BASCOM compiled Basic is 3x faster than MBASIC interpreted Basic. And, checks out. Fact.

Benchmarking - Mandelbrot colour.bas

• Searle MS Basic 4.7 Std 11'46" - 100%
  
• feilipu MS Basic 4.7 Std 10'43" - 91%
  
• feilipu MS Basic 4.7 APU 10'05" - 86%
• Microsoft BASCOM 5.3a Std 3'45" - 32%

Yes, so if anyone has access to the BASCOM library BASLIB.REL source code, it would be great to integrate that with APU code.

Phillip

Phillip Stevens wrote:

Over the last month I've been working on MS Basic.

MS BASIC 4.7c - RC2014

Initially, I started with MS Basic support as my APU stretch goal, but working on it turned out to be a worthy goal for RC2014 generally. 

Over the past weeks I've learned a lot about the workings of the MS Basic code, and I hope to have improved on it in some ways.

I thought it might be good to note the changes to the original MS Basic 4.7 code, which generate about 8% improvement in the benchmarks (Mandelbrot, Selection Sort, Pi). 

[Phillip Stevens]

On Sunday, 6 September 2020 , Phillip wrote:

Phillip Stevens wrote:

Over the last month I've been working on MS Basic.

MS BASIC 4.7c - RC2014

Initially, I started with MS Basic support as my APU stretch goal, but working on it turned out to be a worthy goal for RC2014 generally. 

Over the past weeks I've learned a lot about the workings of the MS Basic code, and I hope to have improved on it in some ways.

 

Supported RC2014 Hardware

The linked files are for a Mini, Micro, or Classic RC2014 with 8kB ROM, 32kB RAM, and the MC68B50 ACIA.

It is possible to support other hardware, but that hardware is better covered by more advanced systems (aka CP/M or RomWBW) than booting to MS Basic.

The NASCOM BASIC 4.7 Repository where everything is located.

Let me know with an issue if you find any problems, or here to just chat.

I've not had a reason to touch my implementations of the Microsoft (NASCOM) BASIC for quite some time. The last work was finishing off the code optimisation using faster z80 and 8085 shift instructions, after I'd returned its compatibility with the 8085 CPU, and the 8085 CPU with the Am9511A APU Module.

But since loading HEX programs has become topical recently, I suddenly twigged that had left a hole in the loading code sanity checking. Previously, I'd assumed that a user would load their assembly code before the BASIC code, and therefore simply adjusted the allowed top of BASIC RAM below the origin of the assembly code, before continuing with the loading.

But, what if the user does it the other way around? i.e. loads the BASIC program before the assembly program. If the BASIC program is longer, and reaches past the assembly origin, then the loaded (HLOAD) assembly code would overwrite the loaded BASIC program, and things would become very broken. Not user friendly at all.

So, I've updated the MS BASIC ROM HLOAD keyword to check for the top of used RAM before continuing with the loading process. If there is a BASIC program in the way of the intended location for the assembly program, then the HLOAD will fail with ?OM Error (Out of Memory). I think that's a useful extra check, which might save some frustration.

Cheers, Phillip

[Fred Weigel]

Philip

Linking BASCOM generated REL with my APU.REL *does* improve the speed of BASCOM generated executables. You need to use /O in the compilation -- otherwise the math in BRUN is used.

https://github.com/ratboy666/apu

FredW

[Fred Weigel]

Philip, also 16x16 multiply can use the AM9511 -- in my APU library, I code it as:

;
; INTEGER * INTEGER ===================================================
;
; HL * DE -> HL
;
         PUBLIC   $M9
;
$M9:     MOV      A,L
         OUT      DA9511
         MOV      A,H
         OUT      DA9511
;
         MOV      A,E
         OUT      DA9511
         MOV      A,D
         OUT      DA9511
;
         MVI      A,AM.MUL+AM.SINGL
         OUT      ST9511
         WAIT
         ANI      AM.ZERO SHL 1
         JZ       $M9.2
;
         XRA      A                     ; Z FLAG
         MOV      H,A                   ; RESULT 0
         MOV      L,A
         RET
;
$M9.2:   IN       DA9511
         MOV      H,A
         IN       DA9511
         MOV      L,A
         MOV      A,H                   ; S FLAG
         ORI      1
         RET

BASCOM and F80 call it as CALL $M9

Now WAIT is

 

WAIT     MACRO
         LOCAL    T
T:       IN       ST9511
         RLC
         JC       T
         ENDM

But, AM9511 timing may allow us to simply ignore it... May be worth trying!

[Phillip Stevens]

Hi Fred,

If I remember correctly, I have tried to replace the 16_16x16 multiply with an APU instruction before, but the APU latency was greater than the CPU software function. So, I took it out.

But, I'll give it another go just to see how my memory holds up.

For interest, for the 8085 code using undocumented RL DE, I've unrolled the MLDEBC multiply slightly to make it a bit faster, and moved the error check to the end (but capturing all the overflow to 32 bits) assuming overflow errors are infrequent in this internal array subscript function. Otherwise, all the user maths in BASIC for z80 and 8085 is done in floating point (by the APU).

MLDEBC:                         ; Multiply DE by BC to HL
        LD      HL,0            ; Clear partial product
        LD      A,B             ; Test multiplier
        OR      C
        RET     Z               ; Return zero if zero
        LD      A,8             ; 16 bits (8 iterations)
MLDBLP: ADD     HL,HL           ; Shift partial product left
        RL      DE              ; Shift (rotate) multiplier left
        JP      NC,NOMLAD0      ; Bit was zero - No add
        ADD     HL,BC           ; Add multiplicand
        JP      NC,NOMLAD0      ; No carry
        INC     DE              ; Capture carry for 32 bit overflow
NOMLAD0:ADD     HL,HL           ; Shift partial product left
        RL      DE              ; Shift (rotate) multiplier left
        JP      NC,NOMLAD1      ; Bit was zero - No add
        ADD     HL,BC           ; Add multiplicand
        JP      NC,NOMLAD1      ; No carry
        INC     DE              ; Capture carry for 32 bit overflow
NOMLAD1:DEC     A               ; Count bits
        JP      NZ,MLDBLP       ; More
        LD      A,D
        OR      E
        RET     Z               ; No overflow  
        JP      BSERR           ; ?BS Error if overflow

Cheers, Phillip

[Phillip Stevens]

On Sunday, 19 March 2023. Fred Weigel wrote:

Linking BASCOM generated REL with my APU.REL *does* improve the speed of BASCOM generated executables. You need to use /O in the compilation -- otherwise the math in BRUN is used.

https://github.com/ratboy666/apu

Thanks Fred, I'd forgotten to add this benchmark for the APU with MS Basic Compiler.

 

Performance. BASCOM compiles Basic, and the resulting code is about 3x faster than MBASIC interpreted Basic code. It might be possible to modify the BASCOM libraries (if Source Code were available), and try to do a better job using Z80 instructions or using the APU. The APU would make BASCOM compiled Basic much faster, I would guess.

The OLD Benchmarking - Mandelbrot colour.bas

• Searle MS Basic 4.7 Std 11'46" - 100%
  
• feilipu MS Basic 4.7 Std 10'43" - 91%
  
• feilipu MS Basic 4.7 APU 10'05" - 86%
• Microsoft BASCOM 5.3a Std 3'45" - 32%

Following up with Fred's APU library for some NEW Benchmarking.

It is not as fast as I'd hoped. There's a 10% improvement with the APU in both interpreted Basic and compiled Basic.

It seems (without looking too deeply into this) that the best use of the APU is still only with compiled C code.

But it is definitely worth moving Basic programs over to the compiler.

• Microsoft BASCOM 5.3a APU 3'05" - 26%

via...

B>bascom =colour/o

00000 Fatal Error(s)
24072 Bytes Free

B>l80 colour,apu,colour/n/e

Link-80  3.43  14-Apr-81  Copyright (c) 1981 Microsoft
%Mult. Def. Global $AA
%Mult. Def. Global $AB
%Mult. Def. Global $SA
%Mult. Def. Global $SB

Data    0103    2A59    <10582>

31233 Bytes Free
[0155   2A59       42]

B>colour

Cheers, Phillip

[Fred Weigel]

Philip -- so ~20 instructions vs ~100 instructions. So, you get ~100,000 multiplies/s at 8Mhz CPU

clock. Actually, given the multiply code for the APU, and the APU clocked at ~2 to 3Mhz... I am guessing

that it was "neck on neck". At a 4Mhz CPU, the APU should win. At 8Mhz, guessing a tie. At over, the CPU

would win. This also implies the WAIT cannot be removed... The AM9511 is converting 16->32 and then

doing a 32x32 multiply (as a guess).

So, TLDR, likely not APU latency, probably APU speed. Too bad the part was not pursued further! Also, all calculations

above are "in my head" as are instruction counts. There may, therefore, be egregious errors. YMMV (your

mileage may vary).

[Alan Cox]

But you can in theory drive two APUs at once or do part software... 

[Phillip Stevens]

On Monday, 20 March 2023, Alan Cox wrote:

But you can in theory drive two APUs at once or do part software... 

:-) In practice it also works well. And looks good too.

I've used up to 4 APUs for parallel calculation of planetary motion, but you very quickly run afoul of Amdahl's Law.

The trouble is making sure that intermediate results are available in the right APU for the next calculation, as moving them between APUs is quite time consuming.

Also scheduling when results are expected is complex, and it is almost impossible to keep all the APU being useful at once. I think the practical maximum is really only about two APU threads.

Cheers, Phillip

[Phillip Stevens]

On Monday, 20 March 2023, Fred Weigel wrote:

Philip -- so ~20 instructions vs ~100 instructions. So, you get ~100,000 multiplies/s at 8Mhz CPU

clock. Actually, given the multiply code for the APU, and the APU clocked at ~2 to 3Mhz... I am guessing

that it was "neck on neck". At a 4Mhz CPU, the APU should win. At 8Mhz, guessing a tie. At over, the CPU

would win.

Part of the issue is that the -1DC bin devices only run up to 3MHz, so they have to run at 1/3 of the RC2014 clock, which is only 2.4MHz.

This is a bit wasteful. But the -1DC binned parts are readily available.

I've been thinking of building a -4DC or Intel 8231A solution, which are 4MHz devices. But these 4MHz bins are much rarer, and difficult to source.

Never-the-less, I'm quite keen on building an Intel 8085 + Intel 8231A simple SBC, close coupled APU with a 1/2 rate, at the standard 7.3MHz system clock.

Simply because this would showcase (to me) all of the 8085 and APU code I've been working on over the past years. But, this hasn't eventuated yet.

Perhaps now it might be time to do something about it?

Cheers, Phillip

[Mark T]

Hi Phillip

Just curious, is there a reason for putting the bus connector on the back of the modules instead of the component side?

Is it just a personal preference, or something about the APU module?

Mark

[Phillip Stevens]

On Monday, 20 March 2023, Mark T wrote:

Just curious, is there a reason for putting the bus connector on the back of the modules instead of the component side?

Is it just a personal preference, or something about the APU module?

Mark, LOL. It is a legacy hangover...

The very first serial ACIA Module that Spencer produced was "backwards", i.e. it needed to have its header installed backwards to fit into the the backplane spacing for rest of the original classic modules.

I didn't know this before I started soldering, and of course I made the serial module first (comms first) and put the header on the right way (not "backwards"). Which then meant that I had to solder the rest of the original set of modules with the header on the back so that they would space properly to fit into the backplane.

And about 40 RC2014 modules later, here we are... everything was backwards from that day forwards.

Of course Spencer thinks it is just me being difficult... ;-)

P.

[Mark T]

Actually I think it looks better that way if you are going to continue using that style of 40 pin header.

I though it was only the classic z80 module that was backwards. I had a look at the retired modules on Spencer’s site and see that serial io module was the same.

[Phillip Stevens]

On Sunday, 19 March 2023, Phillip Stevens wrote:

MS BASIC 4.7c - RC2014

Supported RC2014 Hardware

The linked ROMs are for a Mini, Micro, or Classic RC2014 with 8kB ROM, 32kB RAM, and the MC68B50 ACIA Serial Module.

It is possible to support other RC2014 hardware, but that hardware is better supported by more advanced software systems (aka CP/M or RomWBW) rather than booting to MS Basic.

The NASCOM BASIC 4.7 Repository where everything (Z80, 8085, optional APU) is located.

Let me know with an issue if you find any problems, or here to just chat.

I've updated the HLOAD statement to check for the top of used RAM before continuing with the loading process. If there is a BASIC program in the way of the intended location for the assembly program, then the HLOAD will fail with ?OM Error (Out of Memory). I think that's a useful extra check, which might save some frustration.

 Following up on more stuff for RC2014 Classic 32k RAM machines, over the last while I've added quite a few things to my MS Basic 4.7c builds, and just yesterday finished adding in some some interesting new statements to the standard BASIC repertoire.

1. The Z80 builds now have a serial and memory sanity check to make the first launch a little bit easier. But all builds (Z80 and 8085, with and without APU) will now send a BEL on startup, so you can hear your RC2014 is alive if your terminal emulator supports BEL.
2. The WIDTH statement now supports setting the "comma" column width, so that PRINT comma (or tab) spacing can be done without POKE-ing memory locations. This corrects a flaw dating back to the 1970s.
3. Removed some in-line code used for performance optimisation, and the Searle binary number support. Binary numbers can be represented as Hexadecimal, so they're duplicated functions, and I needed to make space to support...
4. Added new MEEK and MOKE statements. These statements can be used to tabulate and print the contents of memory in Hexadecimal, and to view and edit memory, respectively. Using MOKE it is possible to easily enter a small assembly language program by hand, and then view the entered code in memory using MEEK. The names were selected to echo the PEEK and DEEK functions and POKE and DOKE statements, but are multi-byte themed.
5. Streamlined the entry of Hexadecimal numbers using the & keyword. As Microsoft Basic uses signed 16 bit integers for address entry, it can be cumbersome to calculate these by hand. Now simply entering, for example, &nnnn will provide the correct signed integer address to the system, or &nn to provide a hexadecimal parameter. So for example entering an address becomes DOKE &8204,&9000 to write the address 0x9000 to location 0x8204, which is the USRLOC address needed to launch assembly programs with the USR(n) function in these ROMs. The memory can be inspected with MEEK &8200,1 which tabulates and prints 16 bytes from 0x8200.

New Statement Syntax

• MEEK I,J will print J blocks of 16 bytes of memory, commencing from I address.
• MOKE I will commencing editing of memory starting from I address. New byte values are entered in undecorated Hexadecimal, so 0xAB is simply entered as AB. To quit to the command line use CTRL C, or simply enter a blank return.
• WIDTH I,J where I is the terminal width (automatic insertion of CRLF), and J is the comma column width. Setting the width to 0xFF (the default) will disable auto CRLF.

The paint on these additions is still super fresh, so there could be some quirks. But, now a lot of my in-line optimisation code has been removed, the result is actually much closer to the original NASCOM MS Basic listings.

Hope this is useful. Let me know of any problems or feedback, please.

Cheers, Phillip

[Phillip Stevens]

On Saturday, 15 April 2023, Phillip wrote:

MS BASIC 4.7c - RC2014

Supported RC2014 Hardware

The linked ROMs are for a Mini, Micro, or Classic RC2014 with 8kB ROM, 32kB RAM, and the MC68B50 ACIA Serial Module.

It is possible to support other RC2014 hardware, but that hardware is better supported by more advanced software systems (aka CP/M or RomWBW) rather than booting to MS Basic.

The NASCOM BASIC 4.7 Repository where everything (Z80, 8085, optional APU) is located.

Let me know with an issue if you find any problems, or here to just chat.

I've updated the HLOAD statement to check for the top of used RAM before continuing with the loading process. If there is a BASIC program in the way of the intended location for the assembly program, then the HLOAD will fail with ?OM Error (Out of Memory). I think that's a useful extra check, which might save some frustration.

 Following up on more stuff for RC2014 Classic 32k RAM machines, over the last while I've added quite a few things to my MS Basic 4.7c builds, and just yesterday finished adding in some some interesting new statements to the standard BASIC repertoire.

1. The Z80 builds now have a serial and memory sanity check to make the first launch a little bit easier. But all builds (Z80 and 8085, with and without APU) will now send a BEL on startup, so you can hear your RC2014 is alive if your terminal emulator supports BEL.
2. The WIDTH statement now supports setting the "comma" column width, so that PRINT comma (or tab) spacing can be done without POKE-ing memory locations. This corrects a flaw dating back to the 1970s.
3. Removed some in-line code used for performance optimisation, and the Searle binary number support. Binary numbers can be represented as Hexadecimal, so they're duplicated functions, and I needed to make space to support...
4. Added new MEEK and MOKE statements. These statements can be used to tabulate and print the contents of memory in Hexadecimal, and to view and edit memory, respectively. Using MOKE it is possible to easily enter a small assembly language program by hand, and then view the entered code in memory using MEEK. The names were selected to echo the PEEK and DEEK functions and POKE and DOKE statements, but are multi-byte themed.
5. Streamlined the entry of Hexadecimal numbers using the & keyword. As Microsoft Basic uses signed 16 bit integers for address entry, it can be cumbersome to calculate these by hand. Now simply entering, for example, &nnnn will provide the correct signed integer address to the system, or &nn to provide a hexadecimal parameter. So for example entering an address becomes DOKE &8204,&9000 to write the address 0x9000 to location 0x8204, which is the USRLOC address needed to launch assembly programs with the USR(n) function in these ROMs. The memory can be inspected with MEEK &8200,1 which tabulates and prints 16 bytes from 0x8200.

New Statement Syntax

• MEEK I,J will print J blocks of 16 bytes of memory, commencing from I address.

• MOKE I will commencing editing of memory starting from I address. New byte values are entered in undecorated Hexadecimal, so 0xAB is simply entered as AB. To quit to the command line use CTRL C.
• WIDTH I,J where I is the terminal width (automatic insertion of CRLF), and J is the comma column screen width. Setting the width to 0xFF (the default) will disable auto CRLF.

The paint on these additions is still super fresh, so there could be some quirks. But, now a lot of my in-line optimisation code has been removed, the result is actually much closer to the original NASCOM MS Basic listings.

Hope this is useful. Let me know of any problems or feedback, please.

There have been some fixes and updates on these ROMs for BASIC 4.7c arising from some feedback and further testing.

And, I think that things are now pretty close to finished for the time being.

The HexLoadr in the RC2014 repository for the Mini, Micro, and Classic II RC2014 is identical to Z80 builds in my NASCOM BASIC 4.7 repository, but the NASCOM BASIC repository also has equivalent builds for 8085 CPU, Am9511A APU, and combinations with up to 64kB RAM.

• The MEEK statement now produces a ASCII table as well as a HEX table. This makes a nice 72 column wide review of memory.
• MEEK has also been made indirect capable (programmable), so it is possible to output an entire memory map by writing a short BASIC FOR loop, and incrementing through (say) 0x80 16 byte blocks at a time.
  For example:    10 FOR ADDR = &8000 TO &FFFF STEP &800: MEEK ADDR,&80: NEXT

• The MOKE statement now supports continuous editing. Hitting carriage return now just moves on to the next memory location, without changing the existing value.
  To exit use CTRL-C. Byte values are entered in undecorated capitalised HEX.

• The CLS statement now produces the VT100 clear screen string ESC [2J rather than Form Feed, which will now actually clear the screen with the Pi Pico VGA Terminal, etc.

• A significant buffer under-run bug in the interactive line input code was fixed.
  

Here's some example output from MEEK and MOKE, to illustrate usage.

RC2014-8085 - MS Basic Loader
z88dk - feilipu

Cold | Warm start (C|W) ? C

Memory top?
8085+APU BASIC Ver 4.7c
Copyright (C) 1978 by Microsoft
31948 Bytes free

Ok
meek &200,&10

0200:  4D 53 20 42 61 73 69 63 20 4C 6F 61 64 65 72 0D  MS Basic Loader.
0210:  0A 7A 38 38 64 6B 20 2D 20 66 65 69 6C 69 70 75  .z88dk - feilipu
0220:  0D 0A 00 0D 0A 43 6F 6C 64 20 7C 20 57 61 72 6D  .....Cold | Warm
0230:  20 73 74 61 72 74 20 28 43 7C 57 29 20 3F 20 00   start (C|W) ? .
0240:  C3 50 02 C3 E1 02 FF FF FF FF FF EC 0A 56 12 C0  .P...........V..
0250:  21 00 82 F9 AF 32 4D 82 11 14 05 06 5A 21 00 82  !....2M.....Z!..
0260:  1A 13 77 23 05 C2 60 02 F9 CD 0F 07 CD E2 0C 32  ..w#..`........2
0270:  A1 82 32 F0 82 21 35 03 CD 74 13 CD 2C 07 CD 35  ..2..!5..t..,..5
0280:  0A C2 97 02 21 54 83 23 FD A9 02 7E 47 2F 77 BE  ....!T.#...~G/w.
0290:  70 CA 87 02 C3 A9 02 CD 06 0B B7 C2 DD 05 EB 2B  p..............+
02A0:  3E D9 46 77 BE 70 C2 75 02 2B 11 53 83 CD A5 08  >.Fw.p.u.+.S....
02B0:  DA 75 02 11 CE FF 22 A6 82 19 22 51 82 CD EA 06  .u...."..."Q....
02C0:  2A 51 82 11 EF FF 19 11 F0 82 7D 93 6F 7C 9A 67  *Q........}.o|.g
02D0:  E5 21 F9 02 CD 74 13 E1 CD FA 18 21 EA 02 CD 74  .!...t.....!...t
02E0:  13 31 5D 82 CD 0F 07 C3 2B 06 20 42 79 74 65 73  .1].....+. Bytes
02F0:  20 66 72 65 65 0D 0A 00 00 38 30 38 35 2B 41 50   free....8085+AP
Ok
meek &9000,2

9000:  7C 4B 41 20 35 04 77 C5 D2 21 00 58 DC 45 F9 11  |KA 5.w..!.X.E..
9010:  F0 F7 C9 61 25 BE 66 55 55 31 0C F3 D5 FC 7D 97  ...a%.fUU1....}.
Ok
moke &9000
9000 7C? 00
9001 4B? aa
?HX Error
Ok
moke &9000
9000 00?
9001 4B? AA
9002 41? BB
9003 20? CC
9004 35? DD
9005 04? EE
9006 77? FF
9007 C5? 00
9008 D2?
9009 21?
Ok
meek &9000,2

9000:  00 AA BB CC DD EE FF 00 D2 21 00 58 DC 45 F9 11  .........!.X.E..
9010:  F0 F7 C9 61 25 BE 66 55 55 31 0C F3 D5 FC 7D 97  ...a%.fUU1....}.
Ok

Hope this is useful.

Cheers, Phillip

[Spencer Owen]

I've been running some tests on this BASIC ROM for a few days now, and really happy with the way it's turned out.  The MEEK and MOKE commands work well, and feel quite intuitive (Once you get in the habit of putting "&" in front of hex addresses anyway).  

Probably my favourite bit, though, is the BELL command on startup (or ctrl-g) which works great with the new RP2040 VGA Terminal :-)

There are a few ROMs I've already programmed with the older BASIC, but once those run low, I will be using this one going forward.

Cheers

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/a34b2892-a895-47df-8654-7f70643b29b7n%40googlegroups.com.

[Phillip Stevens]

On Tuesday, 25 April 2023, Spencer wrote:

I've been running some tests on this BASIC ROM for a few days now, and really happy with the way it's turned out.  The MEEK and MOKE commands work well, and feel quite intuitive (Once you get in the habit of putting "&" in front of hex addresses anyway).  

Probably my favourite bit, though, is the BELL command on startup (or ctrl-g) which works great with the new RP2040 VGA Terminal :-)

DING. DING. ;-)

 

There are a few ROMs I've already programmed with the older BASIC, but once those run low, I will be using this one going forward.

Thanks for your confidence in this work.

To make it easy to back track specifically  to this ROM and build directly, I've made a HexLoadr release v1.0 in the RC2014 Repository.

I've also added a ROM suitable for a Plus with 64kB of RAM Module, and for those with a RC2014 provided a ROM for the APU Module, to the release too.

Promise not to touch the code again for at least a few months. :-)

Cheers, Phillip

[Phillip Stevens]

On Sun, 30 Apr 2023, Phillip wrote:

On Tuesday, 25 April 2023, Spencer wrote:

I've been running some tests on this BASIC ROM for a few days now, and really happy with the way it's turned out.  The MEEK and MOKE commands work well, and feel quite intuitive (Once you get in the habit of putting "&" in front of hex addresses anyway).  

Probably my favourite bit, though, is the BELL command on startup (or ctrl-g) which works great with the new RP2040 VGA Terminal :-) 

There are a few ROMs I've already programmed with the older BASIC, but once those run low, I will be using this one going forward.

Thanks for your confidence in this work.

To make it easy to back track specifically  to this ROM and build directly, I've made a HexLoadr release v1.0 in the RC2014 Repository.

I've also added a ROM suitable for a Plus with 64kB of RAM Module, and for those with a RC2014 provided a ROM for the APU Module, to the release too.

Promise not to touch the code again for at least a few months. :-)

Hi Spencer,

indeed a few months have passed. Hope you enjoyed the summer months and have been able to spend some time in RC2014 Towers.

We're planning on a new release of z88dk shortly and I've been looking around at relevant documentation to see what could be improved.

And I noted that the MS Basic instructions on the RC2014 Wiki are possibly outdated and need to be updated.

Of course that depends on your delivery status for ROMs.

If you would like, I can add some words to the Wiki to explain MOKE and MEEK, etc.

I'm planning on Going Bush for the few remaining months of the year, but will have time / connectivity for documentation etc.

Otherwise perhaps of interest, I'm planning on a new "RC" project next year, having become interested in building a Rabbit Core (R2000 CPU) and found that hobby solutions hardly exist.

So something new to do.

Cheers, Phillip

[Spencer Owen]

Hi Phillip,

That timing is very fortuitous. I have just been writing up the documentation for the RC2014 Mini II, and just been linking back to your current documentation on GitHub here less than an hour ago!

The Mini II had a silent launch last night, and until I have finished the documentation on the RC2014 website and written the assembly instructions I will not be making a big announcement.  Although hopefully early next week it'll be in a state worthy of flooding social media with.  So, of course, if there is any additional documentation you can add on the Wiki around the enhancements of your ROM then that would be appreciated.

Sadly there has hardly been any progress with RC2014 Towers this summer. Partly this has been weather related, but also I thoroughly underestimated just how much time making up all the RC2014 Pride kits would take.  Still, if I can get electrics up there before the end of summer then maybe there'll be some progress over winter. We'll see.

Have to admit that I'm more than a little jealous that you can just Go Bush for a few months.  I assume this is with your trailer setup that you've been working on? Internet access kind of defeats the purpose though, surely? Well, have a great time anyway.

Cheers

Spencer

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAFC0-0VwGi4pagjqb1L-6cTY9TVoxjeHGr1t-XpX-8o0GtDgvQ%40mail.gmail.com.

[Phillip Stevens]

Hi Spencer,

Had a look. Very nice much, much more compact.

Will the CP/M expansion be fully compatible with the RC2014 Pro and the new CF Module schematic?

I hope so, and it would make a nice little CP/M-IDE platform for me, that I can be comfortable to take with me on the road.

Those instructions on Github are pretty much what I was planning to replicate to the Wiki. So that is the best accurate information to refer to.

Perhaps I would make them a bit less concise and more appealing to read, with some further examples.

Also, I'd probably reference the option to upload a Zen editor and assembler to write, save, and load some larger assembly programs (alongside MOKE and MEEK).

I've not moved these versions of Zen over to your site, out of respect for Phil. But perhaps you'd like to and credit him.

The only difference to his build is that these versions return to Basic on exit, rather than restarting the monitor.

Both options are noted by Neal Crook, the original porter's github repository.

Cheers, Phillip

On Sat, 19 Aug 2023, Spencer  wrote:

Hi Phillip,

That timing is very fortuitous. I have just been writing up the documentation for the RC2014 Mini II, and just been linking back to your current documentation on GitHub here less than an hour ago!

The Mini II had a silent launch last night, and until I have finished the documentation on the RC2014 website and written the assembly instructions I will not be making a big announcement.  Although hopefully early next week it'll be in a state worthy of flooding social media with.  So, of course, if there is any additional documentation you can add on the Wiki around the enhancements of your ROM then that would be appreciated.

Sadly there has hardly been any progress with RC2014 Towers this summer. Partly this has been weather related, but also I thoroughly underestimated just how much time making up all the RC2014 Pride kits would take.  Still, if I can get electrics up there before the end of summer then maybe there'll be some progress over winter. We'll see.

Have to admit that I'm more than a little jealous that you can just Go Bush for a few months.  I assume this is with your trailer setup that you've been working on? Internet access kind of defeats the purpose though, surely? Well, have a great time anyway.

Cheers

Spencer

 

Hi Spencer,

[Spencer Owen]

Hi Phillip,

Yes, the Mini II CP/M Upgrade Kit does include the CF updates that Tadeusz suggested, and it seems to be tolerant of all the same CF cards.  Obviously without an SIO/2 is is not totally compatible with the RC2014 Pro but that's the only real difference.  The ROM on the Mini II can be paged from the CP/M Upgrade, so with this setup there's no need to provide a second ROM just for CP/M.

On the subject of ROMs, due to the Mini II having 128k, I am dividing this in to 8k and 16k banks, and for the likes of your BASIC which fits in to 8k, I was thinking about putting some other software (like Zen) in the 8k above it with a little loader routine.  So, for example, G 2400 would run a loader routine at 0x2400 that copies Zen up to 0x9000, and then G 9000 would run Zen. There's obviously quite a bit of space for several programs in that 8k.  Whilst I never describe myself as a programmer, writing the loader for that (similar to the one I wrote for CP/M on the Pro) is within my capabilities :-)

I think it has only just dawned on me who Neal Crook is.  I know a guy called Neal that I've met at a load of retro events that always has Nascom stuff with him, and always takes an interest in my RC2014 stuff.  I hadn't appreciated that he is the Zen Guy!

Just on a side note, I will be including CamelForth on the Mini II.  In particular a port by Justin Skists which, amongst other things, includes your hex loader routine.  He thought that had a non-commercial licence against it, however, as that's on the RC2014 GitHub page, I figured that would be fine. But just wanted to mention it to you in case I'm missing anything.

Cheers

Spencer

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAFC0-0XxOdXSfUdvO3Q1q1BGczZ%2BxgNWgZ99JNHz8SSZdbGg4A%40mail.gmail.com.

[Phillip Stevens]

On Sat, 19 Aug 2023 at 23:55, Spencer Owen <spe...@sowen.com> wrote:

Hi Phillip,

Yes, the Mini II CP/M Upgrade Kit does include the CF updates that Tadeusz suggested, and it seems to be tolerant of all the same CF cards.  Obviously without an SIO/2 is is not totally compatible with the RC2014 Pro but that's the only real difference.  The ROM on the Mini II can be paged from the CP/M Upgrade, so with this setup there's no need to provide a second ROM just for CP/M.

Excellent. It will be another variant for me, as I have ACIA+PPIDE and 8085+ACIA+CF. But not ACIA+CF. But it’s a 30min fix to build that variant and then it has an actual useful target. 

On the subject of ROMs, due to the Mini II having 128k, I am dividing this in to 8k and 16k banks, and for the likes of your BASIC which fits in to 8k, I was thinking about putting some other software (like Zen) in the 8k above it with a little loader routine.

Good idea to have it in ROM.

So, for example, G 2400 would run a loader routine at 0x2400 that copies Zen up to 0x9000, and then G 9000 would run Zen. There's obviously quite a bit of space for several programs in that 8k.  Whilst I never describe myself as a programmer, writing the loader for that (similar to the one I wrote for CP/M on the Pro) is within my capabilities :-)

I think it has only just dawned on me who Neal Crook is.  I know a guy called Neal that I've met at a load of retro events that always has Nascom stuff with him, and always takes an interest in my RC2014 stuff.  I hadn't appreciated that he is the Zen Guy!

Just on a side note, I will be including CamelForth on the Mini II.  In particular a port by Justin Skists which, amongst other things, includes your hex loader routine.  He thought that had a non-commercial licence against it, however, as that's on the RC2014 GitHub page, I figured that would be fine. But just wanted to mention it to you in case I'm missing anything.

No problem at all. He’s also using the serial code and initialisation from the MS Basic system. So it would be worth doing a diff against the latest hexloadr code to ensure nothing new was missed since he forked it. 

Cheers Phillip

You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/Y-rwRO3xXQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAO93Ptd3M2y1TygPz_ojrCEy3N2UKN10%3DwJryCUQ5K8T-Zubvg%40mail.gmail.com.

--

Sent from a Mobile Device. Replies may appear terse.

[Phillip Stevens]

On Sun, 20 Aug 2023, Phillip wrote:

On Sat, 19 Aug 2023, Spencer wrote:

Yes, the Mini II CP/M Upgrade Kit does include the CF updates that Tadeusz suggested, and it seems to be tolerant of all the same CF cards.  Obviously without an SIO/2 is is not totally compatible with the RC2014 Pro but that's the only real difference.  The ROM on the Mini II can be paged from the CP/M Upgrade, so with this setup there's no need to provide a second ROM just for CP/M.

Excellent. It will be another variant for me, as I have ACIA+PPIDE and 8085+ACIA+CF. But not ACIA+CF. But it’s a 30min fix to build that variant and then it has an actual useful target. 

Hi Spencer,

So I've provided a RC2014 Mini build for the CP/M-IDE.

Installing it should be as simple as

1. Burn the RC2014 Mini ROM.

2. Format a CF Card to FAT.

3. Unzip a (or many) CP/M drive files and drag one (or many) onto the CF card. Start with sys.cpm

4. Power it up, and type cpm sys.cpm

No installers or downloading needed, it should just work.

Please let me know if it doesn't, so I can fix it.

Cheers, Phillip