gfaraday/chibi-pc09
1
0
Fork 0
forked from amberisvibin/chibi-pc09
Code Pull Requests Activity

Update README.md

Browse Source
This commit is contained in:
Amber
2020-08-04 10:09:57 -04:00
committed by GitHub
parent b856763f7e
commit ca4374d414
1 changed files with 5 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
README.md
View File

@@ -1,16 +1,15 @@
# bedroom Z80
# chibi pc-80
### Description:
The bedroom Z80 will be a Z80-based microcomputer with an advanced I/O system, boot scheme, and graphics hardware:
The pc-80 will be a Z80-based microcomputer with an advanced I/O system, boot scheme, and graphics hardware:
- On boot, the coldboot ROM will search a FAT SD card for a bootfile, load it into RAM, and execute it. The bootfile will be a BIN file that is copied directly to RAM. This bootfile can be copied and moved the same as any other file, allowing for easy backup and distribution of boot code. Due to a quirk in the way the Z80 (and CP/M) operates, once the coldboot ROM has finished its work, it will remove itself from the memory address space.
- It will come with 64k of RAM by default. There will be a basic MMU, using 16 2k pages in the upper 32k of RAM. The lower 32k will be static. The MMU will not be very useful unless a RAM expansion is installed. Up to 256 2k pages will be supported, creating a maximum RAM size of 512k.
- It will come with 64k of RAM by default. These are split into 256 256 byte pages, and will be controlled by an MMU on upgraded machines. A memory protection expansion is also possible.
- It will use a full 64k I/O space, using the upper 8 bits as a Device ID and the lower eight bits as a device address. This creates 256 I/O devices with 256 addresses each. This way, the device ID can be left in the upper address register, while the device address register is updated.
- It will use a full 64k I/O space, using the upper 8 bits as a Device ID and the lower eight bits as a device address. This creates 256 I/O devices with 256 addresses each. This way, the device ID can be left in the upper address register, while the device address register is updated. This is not the most efficient way to do things, but it makes programming very easy.
- The graphics system will be more advanced than most homebrew computer projects. It will have a custom TTL logic graphics card that will be able to display 320x200 in 256 colours over VGA. If possible, there will be a high res mode, at 640x400 in 4 shades of grey. There will be 64k of double-buffered VRAM, interfaced via commands. These commands will include aan auto-change funcion, allowing entire images to be copied with ease. It will also have a text mode, utilizing bitmap copy from the character ROM.
- The graphics system will be more advanced than most homebrew computer projects. It will have a custom TTL logic graphics card that will be able to display 320x200 in 256 colours over VGA. There will be 64k of double-buffered VRAM, interfaced via commands. The buffer will not copy unless a 'done' command is sent. This way, if the frame is not ready, the previous frame will be displayed, preventing tearing. These commands will include an auto-increment function, allowing entire bitmaps to be copied with ease. It will also have a text mode, utilizing bitmap copy from the character ROM.
### Todo: