1
0
mirror of https://github.com/hsoft/collapseos.git synced 2024-11-26 08:48:05 +11:00

Compare commits

...

2 Commits

Author SHA1 Message Date
Virgil Dupras
08328b86a9 doc: add reverse engineering notes for trs80-4p 2020-02-21 10:39:51 -05:00
Virgil Dupras
bd38d46892 recipes/trs80: fix double line feeds
Lines should be terminated only with a CR on this system, not CRLF.
2020-02-21 08:40:42 -05:00
4 changed files with 54 additions and 0 deletions

View File

@ -210,3 +210,34 @@ always successful.
66 BANK B=func C=bank BZ Memory bank use
67 BREAK HL=vector HL Set Break vector
68 SOUND B=func - Sound generation
## Personal reverse engineering
This section below contains notes about my personal reverse engineering efforts.
I'm not an expert in this, and also, I might not be aware of existing, better
documentation making this information useless.
### Bootable disk
I'm wondering what makes a disk bootable to the TRS-80 and how it boots it.
When I read the raw contents of the first sector of the first cylinder of the
TRS-DOS disk, I see that, except for the 3 first bytes (`00fe14`), the rest of
the contents is exactly the same as what is at memory offset `0x0203`, which
seems to indicates that the bootloader simply loads that contents to memory,
leaving the first 3 bytes of RAM to either random contents or some predefined
value (I have `f8f800`).
A non-bootable disk starts with `00fe14`, but we can see the message "Cannot
boot, DA TA DISK!" at offset `0x2a`.
I'm not sure what `00fe14` can mean. Disassembled, it's
`nop \ rst 0x28 \ ld b, c`. It makes sense that booting would start with a
service call with parameters set by the bootloader (so we don't know what that
service call actually is), but I'm not sure it's what happens.
I don't see any reference to the `0x2a` offset in the data from the first
sector, but anyways, booting with the non-bootable disk doesn't actually prints
the aformentioned message, so it might be a wild goose chase.
In any case, making a disk bootable isn't a concern as long as Collapse OS uses
the TRS-DOS drivers.

View File

@ -76,6 +76,9 @@ printnstr:
pop bc
ret
; Prints a line terminator. This routine is a bit of a misnomer because it's
; designed to be overridable to, for example, printlf, but we'll live with it
; for now...
printcrlf:
push af
ld a, CR

View File

@ -151,6 +151,10 @@ A memory range dumped this way will be re-loaded at the same offset through
using the `RUN` command. Therefore, you can avoid all this work above in later
sessions by simply typing `recv` in the DOS prompt.
Note that you might want to turn `debug` off for these commands to run. I'm not
sure why, but when the debugger is on, launching the command triggers the
debugger.
## Sending binary through the RS-232 port
Once you're finished punching your program in memory, you can run it with
@ -186,6 +190,12 @@ If there was no error during `pingpong`, the content should be exact.
Nevertheless, I recommend that you manually validate a few bytes using TRSDOS
debugger before carrying on.
*debugging tip*: Sometimes, the communication channel can be a bit stubborn and
always fail, as if some leftover data was consistently blocking the channel. It
would cause a data mismatch at the very beginning of the process, all the time.
What I do in these cases is start a `COMM *cl` session on one side and a screen
session on the other, type a few characters, and try `pingpong` again.
## Running Collapse OS
If everything went well, you can run Collapse OS with `g3000<space>`. You'll

View File

@ -18,6 +18,9 @@
.equ STDIO_PUTC trs80PutC
.inc "stdio.asm"
; The TRS-80 generates a double line feed if we give it both CR and LF.
.equ printcrlf printcr
; *** BASIC ***
; RAM space used in different routines for short term processing.
@ -44,4 +47,11 @@ init:
call basInit
jp basStart
printcr:
push af
ld a, CR
call STDIO_PUTC
pop af
ret
RAMSTART: