Change of keybindings and request for testing
Lawrence Woodman
I have pushed the keybinding changes that DuLac and I have been talking
about to GitHub.
It would be great if anyone could test this state of the repo and then
if we are happy it can be released as v0.4.1, and then work can begin on
the checksum problem for v0.4.2
Thank you in advance
Lorry
--
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry, CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com
Steve
Edwin is also putting together a Linux box to do some testing.
Steve.
DuLac
After adding
#define XACE_VERSION "0.41"
to the top of the file, everything seems ok, as before.
Ctrl-Q works fine. Also does ESC.
> It would be great if anyone could test this state of the repo and then
> if we are happy it can be released as v0.4.1, and then work can begin on
> the checksum problem for v0.4.2
Will leave that to Steve who has both Win and Lnx.
Lawrence Woodman
DuLac wrote:
> Compiling gets a single error: XACE_VERSION not defined.
>
> After adding
> #define XACE_VERSION "0.41"
> to the top of the file, everything seems ok, as before.
>
You may want to download the latest version into a new directory. The
version that you uploaded to the Jupiter Ace Forum, had multiple copies
of the same or similar files with different names, e.g. Imakefile,
Imakefile.txt. I'm guessing that this is what is happening here. The
definition for XACE_VERSION is in both Imakefile and makefile.org
> Ctrl-Q works fine. Also does ESC.
>
Glad to see that it is working.
bfn
Lawrence Woodman
Steve wrote:
> I will test later.
>
> Edwin is also putting together a Linux box to do some testing.
>
Great to have another tester.
bfn
Marcos Cruz
> It would be great if anyone could test this state of the repo and then
Lenny.
Looking forward for the TAP checksum and especially the file spooling.
Then I will be able to teste it deeply.
Marcos
--
http://programandala.net
Lawrence Woodman
Marcos Cruz wrote:
> On 12 jun, 08:57, Lawrence Woodman <lwood...@vlifesystems.com> wrote:
>
>> It would be great if anyone could test this state of the repo and then
>>
>
> It compiled and worked like a charm here, on Debian GNU/Linux 5.0
> Lenny.
>
Excellent, thanks for the report. Could you let me know what processor
that was: Intel, amd, 32/64 bit, etc?
> Looking forward for the TAP checksum and especially the file spooling.
> Then I will be able to teste it deeply.
>
I'm looking forward to getting some movement on those too. When I get a
chance I'd like to pick you brains on the checksum as I noticed your
.TAP file checker.
bfn
Marcos Cruz
>> Lenny.
> Excellent, thanks for the report. Could you let me know what processor
> that was: Intel, amd, 32/64 bit, etc?
Intel Celeron-M, 32-bit, 900 MHz.
Regards,
Marcos
Marcos Cruz
> I'm looking forward to getting some movement on those too. When I get a
> chance I'd like to pick you brains on the checksum as I noticed your
> .TAP file checker.
For a unfinished project of mine, I wrote a Forth word to calculate the TAP
checksum of a memory zone, but it's not tested yet:
: checksum ( a u -- b )
1- swap dup c@ rot swap bounds
do i c@ xor loop
;
I followed the information I found about the TAP format in the docs of the old
Z80 ZX Spectrum emulator for Windows. Sure you already know:
\ TAP file format (from the Z80 Spectrum emulator documentation):
\ The .TAP files contain blocks of tape-saved data. All blocks start with two
\ bytes specifying how many bytes will follow (not counting the two length
\ bytes). Then raw tape data follows, including the flag and checksum bytes. The
\ checksum is the bitwise XOR of all bytes including the flag byte. For example,
\ when you execute the line SAVE "ROM" CODE 0,2 this will result:
\
\ |------ Spectrum-generated data -------| |---------|
\
\ 13 00 00 03 52 4f 4d 7x20 02 00 00 00 00 80 f1 04 00 ff f3 af a3
\
\ ^^^^^...... first block is 19 bytes (17 bytes+flag+checksum)
\ ^^... flag byte (A reg, 00 for headers, ff for data blocks)
\ ^^ first byte of header, indicating a code block
\
\ file name ..^^^^^^^^^^^^^
\ header info ..............^^^^^^^^^^^^^^^^^
\ checksum of header .........................^^
\ length of second block ........................^^^^^
\ flag byte ............................................^^
\ first two bytes of rom .................................^^^^^
\ checksum (checkbittoggle would be a better name!).............^^
\
\ A tape header always consists of 17 bytes:
\
\ Byte Length Description
\ ---------------------------
\ 0 1 Type (0,1,2 or 3)
\ 1 10 Filename (padded with blanks)
\ 11 2 Length of data block
\ 13 2 Parameter 1
\ 15 2 Parameter 2
\
\ The type is 0,1,2 or 3 for a Program, Number array, Character array or Code
\ file. A SCREEN$ file is regarded as a Code file with start address 16384 and
\ length 6912 decimal. If the file is a Program file, parameter 1 holds the
\ autostart line number (or a number >=32768 if no LINE parameter was given) and
\ parameter 2 holds the start of the variable area relative to the start of the
\ program. If it's a Code file, parameter 1 holds the start of the code block
\ when saved, and parameter 2 holds 32768. For data files finally, the byte at
\ position 14 decimal holds the variable name.
Lawrence Woodman
Excellent, that is just what I needed. I thought it worked like that,
but you have saved me some time and digging to confirm it.