overCLK

Sorry if I didn't make it clear, but my CP/M BIOS relies on ST BIOS/XBIOS, that is the tricky part. If I disable interrupts I won't get any keyboard input using BIOS conin. I've checked the memory maps generated in github project thotto/tos1x and seems to be something up to $a858, so it would be difficult to go below that without compromising stability, since I don't know exactly what part of that memory can be relevant for the BIOS/XBIOS routines I'm using. I experimented with TPA starting at $8000 and even tho it mostly works, some programs fail and it's hard to figure out if it's due to overwritten memory or something else is going on.. I was wondering if there is any emulator supporting breakpoints on memory address write, I was checking with Hatari but it seems it's not supported or at least I didn't find a way to do it. Any idea?

Oh, this is an interesting approach to learn what goes on on those memory areas. I also generated TOS from sources (as found on github project th-otto/tos1x) and the generated map files are quite interesting too!

Thanks a lot Cyprian I'm wondering if sys vars is all we can expect to find there. I tried to check with the Hatari emulator, just put a breakpoint in $1704 with the emulator configured to run on a 68000 and with the 1.04 TOS ROM. So I get control of the system right before my bootloader starts running and I can see data from $600 upwards. Non-zero bytes and maybe I'm wrongly assuming the memory is cleared before the bootloader program takes control: - At $90E - $96B - At $9F0 - $A50 - At $C50 - $C90 - At $D80 - $DA0 - At $E10 - $EC0 - At $16D0 - $17E0. This seems to be the bootsector and something else and some more bytes here and there. Of course what I don't know is if this data can be safely overwritten because it won't be used anymore or BIOS/XBIOS calls could be involved.

I did think about that, but that would lead to a more complex CP/M BIOS reimplementing things that are already in ROM with all the differentiation for the different OS versions and/or hardware. It's a path I wouldn't like to take unless I see no other option. My aim here is mainly to understand why that low memory is taken and if there are ways to minimize it.

Well, it is like that. It is working now but I would like to take over more memory and not hardcode anything Oh, of course I'm listening and learning. This is why I asked here in the first place

Not really. CP/M core must be linked to an absolute address during the build, assuming it will be located at a fixed address. My expectation was that since I'm not using TOS at all (well, at least not after taking over on the floppy boot sequence) I should be able to assume most of the RAM would be usable. Problem is that I've also read this in the Atari Compendium about getmpb() An application should never attempt to modify any of the returned information nor make any assumptions about memory allocation because of this function But didn't find a real justification. It's also true this is not really an application, so I don't know to what extent this information would apply. I think I would need to dig into the ROM routines that setup the information eventually returned by getmpb() to see what is that lower memory used for

Thanks a lot! Even if it's still in a beta stage and I expect to keep improving it I have published it already here: teiram/atari-st-cpm: CPM68K Port for the Atari ST Computers (github.com) Yes, hardcoding is just an initial approach but the idea would be to call this function to get the free memory and set there the TPA for CP/M 68K I'm taking control from the floppy bootloader. I never return control to TOS and I just expect BIOS and XBIOS, and currently also GEMDOS (just for rwabs) to work. But when I placed the TPA at $600 things went bad. That is why I was asking what that memory (anything between $600 and the video RAM) could have being used for. Is there any documentation where this can be found? I guessed it might be buffers or control variables for BIOS/XBIOS functions, but it would be nice to be able to lower the TPA as much as possible, since that will allow to run binaries that were already linked to a fixed start address. Is there a programmatic way to know this address? I don't plan to use TOS at all, I could do just with BIOS/XBIOS and even avoid using GEMDOS. Basically I want to maximize the TPA for CPM68K but in a safe way so that for any ST system I won't clash into any memory that the system is expecting to be free. But getmpb() maybe is not the way to go, because it is returning a higher address than I should expect. Maybe it's taking into account TOS needs? Sure, I even have a printed version of that book in Spanish. Remember to have found it out of luck in a local library when I was 16 and I was new to the Atari ST. It is a remarkable poor quality binding and most of the pages are already lose

Hello there, I'm working in a CPM 68K Atari ST BIOS that relies on the native BIOS/XBIOS in the ST. Initially I manually set the TPA starting at $600 because in the Atari ST Memory Maps I found, it seems that such area should be empty and not used for system variables, that should go up not beyond that point. But after some unexpected problems and realizing that the BIOS function getmpb returns a free memory start address at $a84e I moved the CP/M TPA there and the problems were gone. Now I'm wondering if this makes any sense, and why all that memory from $600 to $a84e seems to be locked. I have seen in the emulator that something gets written into that zone ocasionally but I don't know how this free memory start address is calculated or what this area of memory is used for. Do you have any info about this or any documentation that might be useful to understand it? Best regards

I have to say I found the problem to the first issue. It turned out I was using an exec.bin and grom.bin for the emulator that were not the versions the intellivision has (I think they were provided with the emulator) and I was not aware of it let alone think that the problem could be there. I got another version and now things seem to match quite better 😄 this ROM jumps to $1026 and all seems consistent until we run out of the limited bits my analyzer is able to sample, but looks really good. Next stage will be to check if the CPLD is properly detecting the accesses to the cartridge and providing the expected value back in the bus on the proper phase. Cheers! Manuel

The CPLD is powered at 3.3V, so it's most likely a spike. I was curious and tried to check a normal, longer width ADAR, to see how it looks like. You can see in blue the ADAR function of BC1/BC2/BDIR and in yellow my "cleaned up" version that triggers a bit later because it waits for two samples at 20Mhz to really enable ADAR and get rid of the mentioned glitches due to BC1/BC2 phase differences.

Hello there! Long story short: Got myself a french intellivision (with the SECAM mod) and modded it for RGB output, but since I only have a game (Astrosmash), was interested into trying to make my own homebrew cartridge. This is how I ended up reading this interesting thread and even tho I think I understand the idea, I'm a bit stuck now with my experiment, so coming here to see if you guys with your expertice and knowledge about the hardware can shed some light on my path as newbie in the intellivision field. Don't know if it would be better to open a different thread but since this one is about homebrew cartridges, maybe it's more useful to have all the information together. So basically my attempt is based on a Xilinx CPLD xc95144xl, which is 5V tolerant and I think it should be enough to decode the signals, latch the address requested by the CPU and do the needed decoding of the address to drive a ROM/RAM,... So far I have a prototype board with the CPLD and two 8 bit ROMs working in parallel to provide the cartridge content. I tried to do combinational decoding of BDIR, BC1 and BC2 but found out on the analyzer output that sometimes I got some spurious ADAR phases (very short ones), seems that because there is a little offset between BC1 and BC2 changes (don't know if this could be some defect of my intellivision) and this leads to a detection of ADAR by the CPLD (attaching a capture of the oscilloscope just for sharing). I was able to remove that by using some sort of debouncing approach (sampling with a fast clock in the CPLD and discarding short pulses on ADAR), and now I'm trying to validate address latching. I'm doing it on the falling edge of BAR and ADAR but I'm not sure at all of the results. I connected the analyzer to the address bus and sampled the lower address bits on the falling edge of my "latch clock" what is (ADAR or BAR) getting results that don't match what I expect comparing it with jzintv debug. But maybe (most likely) I'm missing something here. So my first reads of the address bus are (I have only the 7 lower bits): 0000 0001 0002 0026 0027 0028 0029 002A But my understanding is that since the reset vector is in $1000 and this is the dissassembly of the EXEC there: I should expect rather something like: 0000 0001 0002 0029 ... or am I missing something? Is there any other reason why I could have those reads? This is just the offset between my BC1 (blue) and BC2 (yellow) what led to that short ADAR spike (purple) I was commented before Cheers! Manuel