Thanks for that great rom
I have made some changes in the 'series generator' routine.
In the 1st round of the generator loop the operands (and the results too) were zeros.
The improved version skips this 1st round, so saves some times:
Code: Select all
; ; The initialization phase. ; .db $3A ;;mul-by-2 2*x DEFB $C0 ;;st-mem-0 2*x DEFB $02 ;;delete . DEFB $A0 ;;stk-zero 0 ;;- DEFB $C2 ;;st-mem-2 0 .db $C1 ;;st-mem-1 0 .db $2D ;;duplicate 0,0. .db $2F ;;jump .db G_LOOP1-$ ;;to G-LOOP1 - skip the 1st round ; ; a loop is now entered to perform the algebraic calculation for each of ; the numbers in the series ; G_LOOP DEFB $2D ;;duplicate v,v. (old round 1: 0,0) DEFB $E0 ;;get-mem-0 v,v,2*x (old round 1: 0,0,2x) DEFB $04 ;;multiply v,v*2*x (old round 1: 0,0) DEFB $E2 ;;get-mem-2 v,v*2*x,v (old round 1: 0,0,0) DEFB $C1 ;;st-mem-1 v,v*2*x,v (old round 1: 0,0,0) DEFB $03 ;;subtract v,v*2*x-v (old round 1: 0,0) G_LOOP1 DEFB $34 ;;end-calc ; ; the previous pointer is fetched from the machine stack to H'L' where it ; addresses one of the numbers of the series following the series literal. ; CALL stk_data ; routine STK-DATA is called directly to ; push a value and advance H'L'. CALL GEN_ENT2 ; routine GEN-ENT-2 recursively re-enters ; the calculator without disturbing ; system variable BREG ; H'L' value goes on the machine stack and is ; then loaded as usual with the next address. DEFB $0F ;;addition DEFB $01 ;;exchange DEFB $C2 ;;st-mem-2 DEFB $02 ;;delete DEFB $31 ;;dec-jr-nz DEFB G_LOOP-$ ;;back to G-LOOP ;
there seems to be a problem: this file contains in variable A$ the source code for an assembler file (for ASDIS). The basic program contains only REM.
If the program is loaded e. g. by EO and ZX81.rom and I press RETURN, the listing is written to screen and the Zeddy is alive.
If the program is loaded by EO and ZX81x2.rom and I press RETURN, the listing is written very very slowly to screen, additional blank lines are written to screen and the Zeddy freezes.
Any ideas what goes wrong?
I have the same problems as siggi. I can add the following informations:
The first line stays allways on top. Even a CLS-command cann't clean it. The second line is also currupted. Please the pictures.
On the first photograph you can see how the lines are wrong placed. On the second the second line is normaly filled. Now in the third line is the contend of the second line and so on.
Did you know that the d-file of your program is longer than should be?
It contains 32 extra bytes after the latest N/L character in front of the beginning of the variables.
Sysvar D_FILE ($400C) points $40F3, and the VARS ($4010) points $442C.
The difference is $0339 (825 dec) instead of $0319 (793 dec)
It causes the problem.
This means, ASDIS - our assemblerprogram - could have a bug. Do You have an explanation, why this phenomenon dont't show up with the original ZX81-ROM?
The original CLS (more exactly the LOC-ADDR) routine uses the sv. VARS as a pointer, from which it is searching and counting backward the N/L characters (24+1) to get exact line address. So it skips those 32 extra bytes.
Then it prints 24x32 (768) "space" characters to clear the screen using routine PRINT-SP.
The renewed routine assumes that VARS points to the first byte after the D-File.
It looked like I could just switch one ROM image for another but on the ZX Next SD Card the ROM image is 32K.
- Posts: 2987
- Joined: Mon Sep 26, 2011 10:56 am
- Location: Looking forward to summer in Somerset, UK...
I could maybe see why the Next may have a 16K byte ROM image (that’s the size of the ROM in the memory map), but not a 32K byte ROM image. Unless the ROM file is ZX Spectrum 128K / +2 sized. These machines use bank switching to swap between the top ‘half’ and the ‘bottom’ half of a physical 32K byte ROM chip.
The "Emulator ROM" might contain emulator code in there, that's my thinking.1024MAK wrote: ↑Sat Feb 15, 2020 3:51 pmI could maybe see why the Next may have a 16K byte ROM image (that’s the size of the ROM in the memory map), but not a 32K byte ROM image. Unless the ROM file is ZX Spectrum 128K / +2 sized. These machines use bank switching to swap between the top ‘half’ and the ‘bottom’ half of a physical 32K byte ROM chip.