mirror of
https://github.com/hsoft/collapseos.git
synced 2024-11-02 20:30:56 +11:00
Compare commits
No commits in common. "08328b86a90a84728783032d0b7af195818fbfc0" and "0f2b3aca24f4e3ea6da8a0a8b0c719b5bc55e8fb" have entirely different histories.
08328b86a9
...
0f2b3aca24
@ -210,34 +210,3 @@ always successful.
|
|||||||
66 BANK B=func C=bank BZ Memory bank use
|
66 BANK B=func C=bank BZ Memory bank use
|
||||||
67 BREAK HL=vector HL Set Break vector
|
67 BREAK HL=vector HL Set Break vector
|
||||||
68 SOUND B=func - Sound generation
|
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.
|
|
||||||
|
@ -76,9 +76,6 @@ printnstr:
|
|||||||
pop bc
|
pop bc
|
||||||
ret
|
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:
|
printcrlf:
|
||||||
push af
|
push af
|
||||||
ld a, CR
|
ld a, CR
|
||||||
|
@ -151,10 +151,6 @@ 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
|
using the `RUN` command. Therefore, you can avoid all this work above in later
|
||||||
sessions by simply typing `recv` in the DOS prompt.
|
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
|
## Sending binary through the RS-232 port
|
||||||
|
|
||||||
Once you're finished punching your program in memory, you can run it with
|
Once you're finished punching your program in memory, you can run it with
|
||||||
@ -190,12 +186,6 @@ If there was no error during `pingpong`, the content should be exact.
|
|||||||
Nevertheless, I recommend that you manually validate a few bytes using TRSDOS
|
Nevertheless, I recommend that you manually validate a few bytes using TRSDOS
|
||||||
debugger before carrying on.
|
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
|
## Running Collapse OS
|
||||||
|
|
||||||
If everything went well, you can run Collapse OS with `g3000<space>`. You'll
|
If everything went well, you can run Collapse OS with `g3000<space>`. You'll
|
||||||
|
@ -18,9 +18,6 @@
|
|||||||
.equ STDIO_PUTC trs80PutC
|
.equ STDIO_PUTC trs80PutC
|
||||||
.inc "stdio.asm"
|
.inc "stdio.asm"
|
||||||
|
|
||||||
; The TRS-80 generates a double line feed if we give it both CR and LF.
|
|
||||||
.equ printcrlf printcr
|
|
||||||
|
|
||||||
; *** BASIC ***
|
; *** BASIC ***
|
||||||
|
|
||||||
; RAM space used in different routines for short term processing.
|
; RAM space used in different routines for short term processing.
|
||||||
@ -47,11 +44,4 @@ init:
|
|||||||
call basInit
|
call basInit
|
||||||
jp basStart
|
jp basStart
|
||||||
|
|
||||||
printcr:
|
|
||||||
push af
|
|
||||||
ld a, CR
|
|
||||||
call STDIO_PUTC
|
|
||||||
pop af
|
|
||||||
ret
|
|
||||||
|
|
||||||
RAMSTART:
|
RAMSTART:
|
||||||
|
Loading…
Reference in New Issue
Block a user