Description

In order to waste as little space as possible in our limited memory, I would like to harness the flexible memory mapping in the NES II cartridge to allow me to effectively add more system code to the BIOS area after boot in the form of binary overlays

Acceptance criteria

• PLD is updated to map high physical SRAM to low cart area in MODE 0 and map high physical SRAM to ROM area in MODE 2
• BIOS immediately copies itself to high-RAM and then switches high-RAM into the BIOS area
• BIOS uses a flag in the ROM area to check whether it's already running out of RAM or not and not swap if it is
• BIOS linking has been updated for efficiency so that it's not full of big useless holes
• DONKEY and MARIO loaders are updated to start in MODE 2 and switch to MODE 1 for second-half PRG load

Description

For our NES to truly be just a PC, it needs a killer app to draw in the consumers. To this end, we want to port a copy of MS BASIC to the system.

Acceptance criteria

• MS BASIC fork can be loaded from disk from the shell
• MS BASIC fork shows the startup message and gets to the prompt when loaded
• Typing characters into MS BASIC displays characters at the prompt

Description

With the read-only filesystem basically working and an ability to load and run large binaries from disk, the next logical step is to slap some NES cart payloads onto the disk along with a little loader binary that can do the loading and jump into the cart -- just like we were doing with raw disk NES games, but pulling from the FS instead (so ostensibly we should be able to put multiple games on the disk)

My general idea is to extract the binary file loading from the run command and into its own os function that the loader can also use. Then we can have the loader, two 16k PRG files, and an 8k CHR file on the disk. The PRG files we can just make self loading so that the loader stub literally just has to effectively do a "load mario_a.prg" and it'll put itself into the right area.

A tricky thing here is that we have to use 100% of the cart SRAM to store the game code, so this is also going to need to involve making sure we can load all of NOS and the loader stub into the RAM available in the NES. Which is like 768 bytes or so. (2k - 0.25k ZP - 0.25k stack - 0.25k sector buffer - 0.25k twos buffer - 0.25k text buffer = 2k - 5(0.25k) = 2k - 1.25k = 0.75k). Might be able to get away with stealing the text buffer to get a full 1k.

Acceptance Criteria

• Test actually running a binary using the run command
• Move NOS load position to just above the text buffer, make sure it can fit into ~3 sectors and run properly
• Extract binary load code into NOS itself, update run command to call into it
• Write script to transform an iNES into two PRG binaries with 0x8000 load address and one CHR binary
• Create loader binary that can load first PRG, swap cart SRAM mapping, load second PRG, read CHR into CHR RAM, and finally switch into cart mode and jump to the reset vector

Description

Now that we have a mechanism for arbitrary floppy seeking and the ability to read through the disk catalog, it should be possible to create a subroutine that can look up and load the tracks and sectors for an individual file. Since Apple DOS defines the binary format as very simply being the load address and size of the payload followed by the payload data, it should be possible to use the Apple II to assemble binary files and then load and execute them on the NES.

This would be a powerful first step to many things, including DOS-based NES game execution and the creation of a self-hosted editor, assembler, and other such utilities.

Acceptance Criteria

• Command processor can handle arguments and handing them to command routines
• Subroutine exists that takes a string pointer as an argument and returns the track/sector of the first pointer sector of the file in the catalog which matches the string (or zero on not found)
• Load and dump the first t/s sector of a file returned by the above subroutine
• Load and dump the first sector of a file from its t/s sector
• Load first sector of file and grab load address and size and display them
• Implement a file open and file read mechanism that can transparently read a file specified by initial T/S list address byte by byte
• Use t/s list, load address, and size to copy file content from disk to the correct load location and dump w/monitor
• Create "run" command that can use the above to load and jump into a binary
• Detect file type in "run" command and reject if it's not a binary

Description

Right now, we wait for around a second for the drive to spin up whenever we feel we might want to turn on the floppy drive, which is basically any time we go to read a sector.

The thing is, for a lot of reads the drive may already be spinning from a previous read because the drive has a switch-off delay built in to help out with exactly this kind of frequent access.

Instead of just waiting a fixed amount of time, a hack that was used back in the day that we should be able to steal is to read from the data latch until we read different values on two subsequent reads since this indicates that the disk is moving.

Acceptance criteria

• Floppy motor wait code has monitor wait swapped out for look-for-changing bytes code
• NOS and NES games have been tested to continue to work properly with this change

Description

The last thing I ended up being blocked on at VCFMW was just getting characters printing out to the VRAM.
I think I had gotten VRAM character data population working, but I definitely hadn't gotten actual character printing working yet.

Acceptance Criteria

• Test and document current status of character print code
• Write character data to VRAM and display on the tile map
• Implement and confirm operation of existing printing code using VRAM
• Make monitor linefeed actually work again
• Fix attributes/palette of second tilemap page
• Fix keyboard key mapping

Description

For maximum flexibility and convenience, it would be nice to have update modules load themselves into the BIOS area simply by placing them on the disk. To that end, I would like the SHELL application to look through the catalog for update files and binary load each one before entering the command processor

Acceptance criteria

• All bios update modules are loaded into the BIOS area when SHELL starts

Description

The hardware is built, the basic debugging firmware and development loop using the EEPROM emulator is working well enough. It is now time to get the disk and controller hooked back up and figure out what our current timing looks like and why it ain't working.

This story is just to re-document how timing is supposed to look, then instrument and document how the current execution does look.

Acceptance criteria

• Re-read 'beneath apple DOS' low-level documentation, document in this issue what signals are important, where they are on the controller card, and what their timings should look like
• Attach logic analyzer to the disk card's important signals, execute the woz boot code, and document what the signals during an attempt to read the disk look like

Description

To prove that our BASIC is the real deal, we're going to need to be able to execute the following program:

10 PRINT "HELLO, WORLD"
20 GOTO 10
RUN

Acceptance criteria

• The above program can be typed into the BASIC interpreter and, when executed, produces infinite "HELLO, WORLD" messages on the screen

Description

If I want the NES to really be a computer, it should really be able to create its own files on disk

Acceptance criteria

• A file can be created on disk by making a call and passing the file name and type
• File creation is implemented in a bios update module

Description

In the ultimate goal of creating some kind of minimal DOS for the NES, it is my intent to use the Apple DOS 3.3 filing system in order to achieve interoperability with my apples and maybe make a move to developing NOS applications on them.

To this end, I want to start by adding a demo command to the current NOS command interpreter that can navigate the FS hierarchy and produce a listing of all the files stored on the disk.

Acceptance criteria

• Read and dump the VTOC sector off an Apple DOS disk
• Update seek subroutine to allow for backward stepping so that we can read arbitrary sectors out-of-order
• Use VTOC sector to read and dump the first catalog sector
• Step through chain of catalog sectors and calculate a total count of catalog sectors and files
• Print file names in catalog entries during catalog step-through

Description

It would be really neat if we displayed an error message if a user tries to run an NES game on an Apple II

Acceptance criteria

• BRUNing MARIO or DONKEY from inside of Apple DOS displays a message and exits back to prompt
• RUNing MARIO or DONKEY in NOS still loads and runs the game

Description

For our BASIC implementation to actually be more than a toy, we have to be able to save and load our code from disk

Acceptance criteria

• SAVE command in MS BASIC uses the system's file write routines to write the current BASIC program to the disk

Description

Since both machines can run the same 6502 machine code, it would be neat if we could detect that we're not on the NES and use the Apple II ROM to print a warning message and exit

Acceptance criteria

• Booting the NOS disk in an Apple II prints a warning message and exits to the BASIC prompt
• Booting the NOS disk in an NES still works as normal

Description

If I want the NES to really be a computer, it should really be able to append to its own files on disk

Acceptance criteria

• An open file can have a byte appended to it by passing the file handle and a byte to a system call
• Active write buffer bytes are written to disk when the file is closed
• Active write buffer bytes are written to disk when writing goes beyond the end of the current sector
• Writing beyond the end of the current sector causes the allocation of a slot in the FS bitmap and addition of the associated T/S to the open file's T/S list
• File write is implemented in a bios update module

Description

If I want the NES to really be a computer, it should really be able to delete files that are on its own disk

Acceptance criteria

• A file can be destroyed on disk by passing its file name to a call
• Deleting a file marks all of the sectors it was using as free in the bitmap
• File deletion is implemented in a bios update module

Description

For our BASIC implementation to actually be more than a toy, we have to be able to save and load our code from disk

Acceptance criteria

• LOAD command in MS BASIC uses the system's file read routines to load the specified BASIC file into the interpreter from disk

Description

As a user of the NES ][ it would be nice if the system were able to time out and drop to the monitor if there's no disk inserted

Acceptance criteria

• Sector read code sets a failure flag and exits in all the following cases rather than retrying forever
  • Checksum mismatch
  • Track mismatch
• Sector read code includes a motor on and call to motor wait at entry which checks the return flag and uses it to fail exit early
• Motor wait call returns a failure flag and exits early in the following cases:
  • Reading data latch never gets a high MSB after several reads
  • Reading subsequent byte never changes after several reads
• BIOS boot code retries boot sector load a couple of times and finally displays a message and drops into monitor
• NOS boot is not broken
• NOS DIR command is not broken
• NOS RUN command is not broken
• DONKEY is not broken

Description

Turns out, per nesii#2, I can totally read a valid sector signature as long as I insert the proper number of NOPs to account for the faster CPU. To that end, it should be possible to do this same NOP adjustment to all the areas in the Woz ROM that do data reads and achieve complete basic sector reading.

Acceptance Criteria

• Able to distinguish between data header and address header
• Able to read address info and dump it via the monitor
• Able to read raw data and dump it via the monitor
• Able to convert raw data to unencoded real values

Description

#3 is closed, and my friend that means we can pull in sectors now. Well, at least the first sector. But that's good enough to pull boot code!

This item is for fleshing out my ability to boot from a floppy and setting up a toolchain around it so that I can get some kind of neato NES DOS going down the line.

Acceptance criteria

• Hand-edited DSK can be written via the IIgs and successfully read on the NES
• NES boot rom is updated to jump into the sector read buffer after a successful read
• PoC boot floppy boots to a 'hello world' message

Description

When scrolling the screen, the NES II BIOS routines currently display a dirty previous line at the very bottom margin of the screen. I don't want that.

Acceptance criteria

• No dirty line at the bottom of the NOS console