ivop

I could probably do that, if I had the hardware Thinking about it some more, the communication between the 6502 and the Z80 needs to be a little more robust to avoid running into a race condition or executing the same BIOS command twice. Perhaps more like: Z80: check if 6502 is ready for command 6502: signal ready for command Z80: send command 6502: recv command Z80: wait for done 6502: halt Z80, do command, signal done, start Z80 Z80: wait for done, recv done, signal ack 6502: wait for ack, recv ack, loop to signal ready for command Z80: continue http://github.com/ivop/atari8080 contains a 8080 emulator I wrote in C and in 6502 assembly. In the C version I did a full BIOS implementation (around 160 lines of C code). The 130XE 6502 version contains just enough BIOS to output the test suite results via CONOUT. I was working on porting it to CP/M-65 to run on top of its BIOS, i.e. translating the 8080 BIOS calls to CP/M-65 BIOS calls. That's mostly finished, but then I got sidetracked by another project It still needs the CP/M-65 overlay loader and read/write sector translation. Then you basically have 95% of the code you need to get your card running if you were to run it on top of CP/M-65. If you look in the cpm22 directory of the aforementioned repo, you'll find a much simpler BIOS skeleton (bios.asm) and the adapted bdos.asm with the needed hardcoded BIOS addresses. If you wanted to to stay closer to what Atari did, you could try extracting the hexdumps from the .MAC files (CPMBIOS, CPMBDOS and CPMCCP, highest .number extension) and run them through a disassembler. BDOS and CCP are unmodified from Digital's sources, except for the hardcoded BIOS entries. Perhaps you can deduct from CPMBOOT where in the Z80 memory they are loaded. Looking at the hexdumps, BDOS does some calls with 0CDH (=CALL) 006H 04AH, or 009H 04AH, etc. (low byte increasing by 3 for each next BIOS call) and the BIOS starts with jumps for each BIOS call (0C3H (=JMP) and then an address in the $4Axx range, total of three bytes per entry). BDOS starts at offset +6 (after the six byte "serial") with JMP BDOSE which is 0C3H and the address 03C11H. BDOS at $3c00 and BIOS at $4a00. Pretty weird numbers if the Z80 had 64kB of RAM. CCP starts with JMP CCPSTART (which is three pages in), .Byte 0C3,05C,037, so CCP should start at $3400. So instead of pages $e4, $ec and $fa (which I had expected and pretty standard across 64kB CP/Ms) they appear to start at pages $34, $3c and $4a. Perhaps they were debug builds? They should be at the end of the TPA (Transient Program Area, read free memory), not somewhere in the middle. TPA from 00100H to 03BFFH (CCP is allowed to be overwritten if the program ends with WBOOT instead of RET) is pretty small and cannot run Zork for example.

That sounds good! Basically it comes down to this: 6502 sets up the Z80 memory map: $0000-$0007 (W)BOOT vector and BDOS vectors ($e400 CCP optional, should reload on (W)BOOT anyway) $ec00 BDOS $fa00 BIOS (2kB should be more than enough) BIOS needs entry points for each call, and a disk parameter block (also called DPH). For BDOS to find BIOS, you have to hardcode all addresses in bdos.asm The disk parameter block is what SELDSK returns in HL. BDOS calls that to know where it is and to know how the disk is formatted. start Z80 (which starts running at $0000, which points to BOOT, changed to WBOOT after that during BOOT, WBOOT always reloads CCP.SYS) each BIOS call does: save parameter A, BC, and HL to a fixed location (say $ff00, ignore DE as we don't do sector translation (sector skew)) signal 6502 we want BIOS call number x busy wait for ACK reload A, BC and HL from memory RET 6502 does: wait for BIOS request stop Z80 dispatch on request number X read Z80's C or BC (depends on call) from memory execute bios call (CONIN, CONOUT, READ/WRITE sector directly in to/out of Z80 memory, etc...) set return values in Z80 memory (A, C, HL, whatever applies) start Z80 signal ACK Short description of BIOS calls: https://www.seasip.info/Cpm/bios.html You can ignore LIST, PUNCH, READER, SECTRAN and LISTST. You could save a copy of CCP outside of the Z80 memory so you can reload it very fast when WBOOT is called. You can start with the Atari E: device as CONOUT, switch to a proper dumb terminal later (so Atari special characters are printed as characters instead), and after that something like ADM-3a or VT-52 in 40 and/or 80 columns. For inspiration you could look at the CP/M-65 terminal implementations. As dmsc would say, have fun!

Yeah, looks like all CR/LFs are missing. Replacing tab by newline+tab makes it sort of readable (sed 's/\t/\n\t/g') but not all. Some files have single CRs at some lines. But with some manual intervention it could be turned into proper source code. Except for the binary blobs (BIOS, BDOS, CCP) which are .byte statement hexdumps of 8080/Z80 code. IMHO it would be easier to write your own BIOS and the Atari side of things. If you know how CP/M works, it's one to two days work to get that working, provided that the card allows the Z80 to be halted after a request is made and the 6502 can access the RAM memory again.

If you want really fast, you could try porting this to the Atari: https://github.com/davidgiven/bogomandel Interesting write ups on his blog. Links are in the README.md. Have fun!

Great work! It would be nice if you used the CP/M-65 diskdefs for the disk format once you assemble a new BIOS so it would be easier to exchange data between them. Is anything known about how the Z80 card communicated with the Atari to trigger BIOS functions? If you have any questions, I could possibly be of help as to how to "trap" BIOS calls and what the Atari should do when it is asked to execute a certain BIOS call. Here's an example where I use OUT to trigger an emulator to do the BIOS stuff: https://github.com/ivop/atari8080/tree/main/cpm22 It also shows how to assemble working BIOS, BDOS and CCP files. Currently it includes the atarihd (1MB) diskdefs, but that could also be the 90kB SD version. Instead of a single OUT and RET, you would need some way to communicate the proper registers to the Atari and read them back after the Atari is finished. You could use a small fixed block of high memory for that. Edit: diskdefs: https://github.com/ivop/cpm65/blob/master/diskdefs

Here's another detokenizer for MAC/65: January 2010. Wow, time flies. To convert Atari's EOL to LF I use an age old Unix tool: tr '\233' '\012'

Yes, very beautiful. I wondered how they did this back in the day. I guess they used some sort of a template ruler? Now I want something like this: https://www.amazon.com/Traceease-Electrical-Drafting-Designing-Measuring/dp/B08VJ9NT2Z?th=1 Looks like fun

If you want people to use your library, it would really help if you had a sample application. Like a simple adventure with five locations where you have a description, can pick things up or drop them, watch your inventory, a door somewhere to open with a key that gives access to another five locations, an NPC you can talk to or give something and get something in return, et cetera. Just basic stuff. Then compile binaries for each platform you support and release a tarball/zipfile with source code which one can rebuild themselves by simple unpacking it somewhere, cd into it, and type make (assuming CC65 is installed).

The LAOO palette located in RastaConverter/Palettes/laoo.act. You can tell RastaConverter which palette it should use for color matching with its /pal=Palette File command line option. I find the default atari800 palette a bit bland. You can also change its palette by setting COLOURS_PAL_EXTERNAL_PALETTE=/absolute/path/to/laoo.act in atari800.cfg.

Looks like ordered dithering. Probably /dither=chess.

Interesting! Sophia 2: Top and bottom left are black. Altirra 4.20: More stuff is wrong, and the small line in the lower right corner changes pixels constantly. No matter what -vert-area option I pass to atari800, it won't display more than 240 lines.

If you drag the resulting image in google's reverse image search (google lens) you can easily find the original. https://images.google.com/ Then click find image source above the image.

Hmm, not much really The small image can run starting as low as an Atari 400 with 16kB of RAM and a SD 810 drive. The larger image needs a drive emulator. The XL image needs 64kB (the CP/M BIOS, BDOS and CCP live under the ROM). It's especially nice to mount them from SIDE2/3 as D1:. In user area 1 there are two Atari specific programs. One to change the 40 column font (setfnt and a few example fonts) to get proper {}~ etc.. The builtin 40 column driver has blank scanlines between the mode 2 lines to avoid ascenders and descenders touching each other. There's also a loadable 80 columns driver I wrote specifically for CP/M. It uses 6x40 bytes per logical line and ANTIC to clear the line above and below, which makes line indexing very fast (one logical line per page, 16 bytes wasted). What else can you do? You can learn about the old CP/M command line and its weird syntax. REN OLDFILE=NEWFILE for example. And user areas instead of directories (and no way to copy between them, really). You can run the native 6502 assembler and assemble some of the utilities like dump and ls (asm dump.asm foo.com). There are two editors. Bedit is old style line based, qe is vi-like and runs on systems with a screen driver (which the Atari port has, both 40 and 80 columns). As said, there's Altirra Basic (not very well tested yet, but it runs). There's Conway's game of life, and a few test programs, like scrntest and vt52test after you have loaded the vt52 driver. The last one is very new and might have bugs. Edit: and of course you can study its source code I found it very interesting to see how CP/M worked back in the day and how David overcame the fixed loading address of binaries which it was known for. How relatively simple it was to get a new 8080 (and later Z80) based computer up and running with a minimal system dependent BIOS, like 3.5kB of BDOS and 2kB for a command line interpreter. The latter two being the same for every system. It's the reason why it is still used by basically anyone that creates yet another Z80-based single board computer. Write a small BIOS (less than 1kB) and your machine is up and running. Now with CP/M 65 and relocatable binaries we have more or less the same for 6502 based systems. Hence all the different ports that only differ at the BIOS level. Everything else is the same and they are binary compatible. You can run the same executable on the Atari or an Oric or any of the other supported systems.

David Given is very strict about everything having a clear license, similar to https://github.com/davidgiven/cpmish . The MS BASIC situation is unclear. There are reverse engineered sources floating around the internet but strictly speaking it is still closed source and MS's IP. Unlike, for example, GW BASIC (https://devblogs.microsoft.com/commandline/microsoft-open-sources-gw-basic/ ). The good thing is that David decided to port Altirra BASIC instead which is known to us

Because of licensing issues there's no MS BASIC for CP/M-65. But David ported Altirra Basic (minus the Atari specific stuff) instead.

Yes, I have (author of the Atari port)

I have solved it yet. Left is OUT, top is OD (clock signal based on RW, CS1 and nPhi2), right is IN. Works correctly in simulation now. Interesting to see that internally the data bus bits 4-7 are always pulled low during a read. It never occurred to me that none of the GTIA read registers use more than 4 bits.

Sorry, I meant top (IN) and right side (OD). Edit: here's the part I mean (inlined a usage example):

Yes. I misread the schematic and swapped to long lines. That's what you get without a hard copy. Looks like the whole rD0 (and rD1,2,3) are open drain, so no bus contention will occur. Sorry, will do that. On page 4 of the GTIA schematics, in the lower left corner there is a large triangle that is used above for reading the databus. The detailed schematic pins do not line up with when they are in use (like other details do). I assume IN as at the top of the triangle and OD is at the bottom. Is that correct?

Hmm, that's not working like I hoped it would. It actually drives the line 0 when not floating instead of pulling it down. Result is bus contention.

You have to create new udev rules to change the names associated with the device IDs of your two joysticks, similar to renaming network devices etc... https://ubuntuforums.org/showthread.php?t=1595666

Yes. It's for joysticks connected to the printer port or D15 connector on the sound card. You probably don't have either anymore on a modern system. That part of the documentation is very outdated. There is no pdcurses target anymore. -joy0 and -joy1 are also for LPT joysticks, not USB. USB joysticks should be auto detected at startup. $ atari800 Using Atari800 config file: /home/ivo/.atari800.cfg Created by Atari 800 Emulator, Version 5.0.0 Joystick 0 found Video Mode: 672x480x32 windowed without vsync Sometimes you need to set Use hat/D-Pad to yes inside atari800. Press F1 and go to controller configuration -> configure real joysticks.

Yes, that's what I expected. I found how to set open drain behaviour in logisim. For every gate you can set the output to 0/1, 0/floating or 1/floating. That's good news Yes, and weird loops that are not directly obvious, like: I understand. DETail makes sense, so I'll go for detail. Thanks!

If you have autogen.sh I guess you did not download the zip-file from the releases page but cloned the repo, right? Not enough information. Could you post the output of configure? On what kind of system are you trying to compile? Are you cross-compiling?

Another question. Sometimes repetitive sub-circuits are referenced by a letter or combination of letters (e.g. W or AD). Sometimes it has the DET prefix (e.g. DET PB). What does DET mean? Google found Dual Edge Triggered (for flip flops) and Detailed Electrical Test. Both do not seem applicable here.