eed002

Thanks. This was helpful as well... https://sites.google.com/site/atari7800wiki/graphics-modes

Hi, Also I see there is an FPGA of Maria, I saw the PDF gatelevel schematics that was found in the garbage, does someone have this in a GIT repository? Thanks

Hi, I am looking for programming information on Maria. Have been searching and splicing together what I have found. I have these questions, wanted to see if someone could help? 1) Where is a good source for detailed Maria operations? 2) When handling a display list for a zone, does each sprite have its own display list with a palette selection, or are all the sprites combined in one list? 3) Does Maria recreate (DMA) all the data into a smaller zone buffer, just before it scanlines out the zone? Is this a temporary storage location, or is there memory for all the zones? 4) If there is a graphics buffer, how many bits per pixel are stored? Why would it need this, if it always DMAs just before rendering? 5) Since there is a double buffer, this implies there is storage for one complete frame, what is stored in there, since there can be many combinations of palettes per sprite, because 2 bits per pixel would not be enough. 6) Last, is there a Discord site for 7800 programming? The best I found was: http://7800.8bitdev.org/ I guess there is a direct and indirect mode. So, in direct 160x2 you are limited to 4 colors per pixel, however how does this tie into the sprite DLL ability of Maria, is this a parallel event? if so then the double buffer mode is only for direct mode, i guess. Thanks. Confused

The ground marked off on the terminal is also different from the drawing, both top views, and they are both are r.D versions. Thanks, eed002

How come the pinout is inverted from the manual?

Thanks for your help. After thinking about this, my biggest problem is fseek and FTP interoperability. I think I will be creating a special DUP.SYS that is parallel to DUP.SYS and called something else (FTPDOS). FTPDOS will look like a standard unix prompt ("R4:> ....(command)"). I will have mount/umount command that will copy a .ATR (from ftp) to ESPFLASH and push out writes to ftp. This will allow my to seek a file based ATR, do sector writes, and sync with the ftp server. However, the FTPDOS will also allow me to access the ftp directory directly and load/save/run/del..., even copy from R4:(ftp) to D1:(sio) and vice versa. This allows me to preserve the desired FMS within the A8 but still have the FTP access that I wanted. This way a subsequent boot, would SIO boot from D1(SIO) if desired. Anyways, this is for a different thread, but still sortof ATR related. Thanks, Ed

The 800XL schematics show the SIO 5V supply line directly connected to the 5V supplied by the external power supply, so 1.5A....working on a similar SIO device, and had the same question. -Ed

Found the Sparata X reference manual...exactly what I needed. However, as I think about my problem, I think the best thing is to not to try and merge the both worlds, but try to create an FTP DOS. Ed

I am working on a simple ultimate SIO peripheral(P: R: D: C:) , SIO2WIFI with an ESP8266. Where for D: access, I was planing on accessing files at an FTP directory. I plan on reusing already existing code for .ATR implementations. However, I wanted a way to just have all the files in the ftp directory, directly accessible, and not part of an ATR structure. My idea was that I could have a virtual directory structure. However, if a dos like sparta needs a FAT located somewhere in the middle of the drive I have a problem. I wanted to parse the ftp directory, create a JSON of all the files, and assign sectors to them. The first 3 sectors would be special, but in essence my special JSON file will have the sector structure. So that, if sparta dos X was what was installed in that ftp directory mount, then its FAT would be non file data that is stored on sectors in the JSON. I would also have to hide the JSON from the OS itself. The problem that I am seeing is that any file that is added via any non-sparta transaction(user drops a file into the directory), those files wont be in the FAT, and sparta wont know about it. For this to work, I need to know where the FAT is located(dos dependent), and update the JSON, every time I reconnect to the ftp directory. I think I am stuck only supporting/serving .ATR files, and my idea for a free directory structure is a dead end. Hence, my desire to know the location of all the FATs, and tables for each OS. Any thoughts appreciated. ( I guess I could pick an OS like Sparta and force those open directories to use that OS, manage the FAT update, and limit my complexity down to one OS.) Thanks, -Ed

Thanks. I thought I was going nuts. I have seen http://fileformats.archiveteam.org/wiki/ATR, and the many DOS specifications, posts, etc...and I thought I was missing something. This helps a lot. Thanks, Ed

All, Its a couple of years, but I am trying to understand the ATR format, for a project I am working on. I have read the posts, and the NICK textfile is great. However, with regards to the ATR format, where is the File allocation table kept? Is there a binary map of empty sectors? An help is appreciated. Thanks, Ed

Hi, I will be receiving 3 PCBs, I can put it together. and send it to you, if you want. I believe all we need to do is handle the SIO R: requests, it should not be that bad. Isn't it a straight through FIFOed interface to the UART? Thanks, -Ed

Hi, Yes, just updated my post and noticed your comment. We can make it an option via SPIFFSS flash upload. Ed

Hi, Just noticed ICET needs 128K. I want to be able to have a solution that works even for a 48K 800. Found this: http://atariage.com/forums/topic/96729-vt100-emulator/ (should of searched atariage first) Looks lime VT100SQ or Omnicomm. We can probably make the term emulator used/changeable via esp8266 SPIFFSS image, so ICET or other options are available. Thanks, Ed

Thanks Venkman!! http://atariage.com/forums/topic/217539-ice-t-xe-276-released/ ICET it is. -Ed