honeylisp/todo.txt

48 lines
1.9 KiB
Plaintext
Raw Normal View History

Game:
* Ending screen
* Intro sequence (how to show earthquake?)
FLOPPY DISK IDEAS:
* I am not going to write my own DOS
* I will use ProDOS - BOOTI-compatible, modern
* ProDOS 2.4.2 - https://prodos8.com/
* Generate file(s) to be injected into a blank bootable ProDOS disk image
thinking:
neut.tower contains all code / data
loader.system contains a small program that maps offsets of 512-byte blocks to memory addresses
- is loaded to 0x2000 & will be wiped by gfx? No, PRODOS is loaded at $2000 and moved
- no, XXX.SYSTEM is loaded to 0x2000 as well
- Alternately, we could write one program that batch-loads the whole game into $2000 and moves it to where it belongs?
- How big is the game with all levels? Could we load the whole thing into consecutive memory starting at $4000?
- (I don't think this would work on 32kb tape-loaded machines...)
- With ProDOS I can assume 64kb
prodos claims:
$bf00-$ffff - ProDOS
$9600-$bf00 - BASIC.SYSTEM - don't care?
$0100-$0800 - "other use or reserved"
$3A-$3F - used by disk routines, unsafe
$40-$4F - used by ProDOS but preserved, safe to use
system bitmap: marks pages of memory as "not valid to allocate a file buffer"
- loader will have to protect memory that it will be moving game code to?
https://prodos8.com/docs/techref/calls-to-the-mli/
the existence of SET_BUF should mean we can load directly to the memory
we care about? orr I guess 512 bytes is housekeeping stuff (index block)
16kb version - $0000-$4000 - no we need at least 32kb
there's basically only 5kb of code space for an hgr game?
$0000-$03ff 0kb-1kb - zp, stack, input buffer, DOS
$0400-$07ff 1kb-2kb - text page 1
$0800-$0bff 2kb-3kb - text page 2
$0c00-$1fff 3kb-8kb - free space
$2000-$4000 8kb-16kb - hgr gfx page 1
tooling ideas:
* REPLy buffer (Polywell?)
2020-12-15 04:14:35 +00:00
* save player positions & map state during hot reload
* debug movement (noclip? teleport? activate by clicking? MAME supports mouse input / debug overlays...)