@zbyti thanks for refering to my presentation :)

You can also find the textual info here:
https://github.com/FreddyOffenga/sizecoding/blob/main/presentations/Atari8bit/presentationA8.md

JAC! did a much longer tutorial about the Atari 8-bit which might be useful if you want to know the basics of the platform. Part 3 and 4 are about the memory map.
https://www.wudsn.com/index.php/productions-atari800/tutorials

Keep up the good work!

from prog8.

master branch now has an atari target, it creates a .xex file but it doesn't run yet because the details need a lot of work still. Maybe you can have a look at it already though to see if this is going anywhere?
It targets an Atari 800 XL and I'm using the Atari800 emulator to attempt to run stuff.

from prog8.

well at least 64tass supports generating xex files so we don't have to adapt the tool chain.

from prog8.

Okay, I'll try to answer these questions soon, I'll consulting with someone more experienced on this platform than me if necessary.

A8 support is not urgent, you know by your self how many people programing on 8-bit in anything other than ASM or BASIC ;)

from prog8.

Atari XL support: @FreddyOffenga explains everything here: https://www.youtube.com/watch?v=ezQuRA1FPJ0 ;)

Freddy contributed to Millfork A8 support, maybe he can help in this case.

1. with OS, $80-$ff is free (BASIC is off by default).

2. Atari uses DOS to load binary files, the headers are important. There is no need (like on C64 or ZX Spectrum) adding BASIC lines to start the program.

from prog8.

Cool thank you! Will take a look and see where or how I can help, probably this weekend.

from prog8.

Maybe you can put RAM on the nes cartridge?
Anyway, for the time being I've removed NES from the list of probable additional target systems...

from prog8.

Some progress has been made here recently, by adding a switch to select the compiler output target.

from prog8.

The commanderX16 target is now the second functional target and it kinda ironed out the kinks that should make it fairly easy to add another target. (as long as we know the machine's memory map and such)

from prog8.

Are you considering at least basic support for 8-bit Atari?

from prog8.

I would love to!!
But I don't know how they work.

What needs to be done is mainly implement the ICompilationTarget and IMachineDefinition objects for it that tell the compiler about memory layout and stuff.

from prog8.

Safe memory location for code is from $2000 to $BFFF then BASIC is off - this is default scenario.

ZP free memory for non BASIC programs is from $80-$FF.

Key registers you can find here: https://github.com/KarolS/millfork/tree/master/include a8_*.mfk

Most simple binary (XEX) for Atari is build this way:

$FFFF begining-LO begining-HI end-LO end-HI [ bytes of our program ] $02E0 $02E1 start-LO start-HI

https://www.atarimax.com/jindroush.atari.org/afmtexe.html

There are other headers for multi segments programs but above is good for start :]

2000: 4C 03 20  JMP $2003
2003: AD 0B D4  LDA $D40B   ;VCOUNT
2006: 8D 18 D0  STA $D018   ;COLPF2
2009: 8D 0A D4  STA $D40A   ;WSYNC
200C: 4C 03 20  JMP $2003

as XEX file looks this way:

FF FF 00 20 0E 20 4C 03 20 AD 0B D4 8D 18 D0 8D 0A D4 4C 03 20 E0 02 E1 02 00 20

Header: first 6 bytes and last 6.

This way you can load one big segment into memory from $2000 to $200E and run program from $2000.

from prog8.

Oh, well I forgot about:

E0 02 E1 02

:D

736-737          	2E0-2E1          	RUNAD

     Used by DOS for the run address read from the disk sector one or
     from a binary file. Upon completion of any binary load, control
     will normally be passed back to the DOS menu. However, DOS
     can be forced to pass control to any specific address by storing
     that address here. If RUNAD is set to 40960 ($A000), then the left
     cartridge (BASIC if inserted) will be called when the program is
     booted.

     With DOS 1.0, if you POKE the address of your binary load file
     here, the file will be automatically run upon using the DOS
     Binary Load (selection L). Using DOS 1.0's append (/A) option
     when saving a binary file to disk, you can cause the load address
     POKEd here to be saved with the data. In DOS 2.0, you may
     specify the initialization and the run address with the program
     name when you save it to disk (i.e.,
     GAME.OBJ,2000,4FFF,4F00,4000). DOS 2.0 uses the /A option
     to merge files. In order to prevent your binary files from running
     automatically upon loading in DOS 2.0, use the /N appendage to
     the file name when loading the file.

     For users of CompuServe, there is an excellent little BASIC
     program (with machine language subroutines) to create autoboot
     files, chain machine language files with BASIC and to add an 850
     autoboot file in the Popular Electronics Magazine (PEM) access
     area. It is available free for downloading.

https://www.atariarchives.org/mapping/memorymap.php

from prog8.

What type of 8 bit atari are we talking about anyway?
Also can you recommend a good emulator for it (preferably running on Linux)?

from prog8.

Atari 800 XL 64KB RAM.

On Ubuntu I use https://atari800.github.io/ - in special cases I use Altirra under WINE.

Run atarti800 from command-line then F8 give you access to the monitor.

from prog8.

Atari 800XL code examples:

https://github.com/zbyti/k65-playground/tree/main/src/a8

https://github.com/tebe6502/Mad-Pascal/tree/master/samples/a8

from prog8.

how to print some text to the screen on 800xl?

from prog8.

You can take screen memory pointer from SAVMSC located at $58, $59.

Also look at:

https://github.com/KarolS/millfork/blob/master/include/a8_kernel.mfk

https://github.com/tebe6502/Mad-Pascal/blob/master/base/atari/putchar.asm

832-847          	340-34F          	IOCB0

     I/O Control Block (IOCB) zero. Normally used for the screen
     editor (E:). You can POKE 838,166 and POKE 839,238 and send
     everything to the printer instead of to the screen (POKE 838,163,
     and POKE 839,246 to send everything back to the screen again).
     You could use this in a program to toggle back and forth between
     screen and printed copy when prompted by user input. This will
     save you multiple PRINT and LPRINT coding.

     You can use these locations to transfer data to other devices as
     well since they point to the address of the device's "put one byte"
     routine. See the OS Manual for more information. Location 842
     can be given the value 13 for read from screen and 12 for write to
     screen. POKE 842,13 puts the Atari into "RETURN key mode" by
     setting the auxiliary byte one (ICAX1) to screen input and
     output. POKEing 842 with 12 returns it to keyboard input and
     screen output mode. The former mode allows for dynamic use of
     the screen to act upon commands the cursor is made to move
     across.

https://www.atariarchives.org/mapping/memorymap.php

from prog8.

I'm not an expert, I always turn off system and write my own procedures to PRINT on screen ;)

from prog8.

I don't like the idea of writing my own PRINT routines, I much rather use a rom routine to put text and numbers on the screen. Is there a list of atari rom routines like this somewhere?

from prog8.

something like this? https://github.com/ilmenit/A800-OS-XL-Rev2

https://atariwiki.org/wiki/Wiki.jsp?page=Atari%20800%20ROM%20OS%20Source%20Listing

https://atariwiki.org/wiki/Wiki.jsp?page=Memory%20Map

https://www.atariarchives.org/mapping/

from prog8.

@zbyti to streamline things in a way to get going, I really need at least parts of a questionnaire filled out for me. Here is the (new) porting guide I wrote: Here is a guide to help fill out the blanks required to add a new target to the compiler: https://prog8.readthedocs.io/en/latest/portingguide.html

As I know next to nothing about the Atari 8bits, I really need someone (you?) to step in and fill in those questions to get things on the road. Not all are required to be answered to get at least a bare bones thing running, but some really are, and I don't have the time to investigate this platform myself now.

from prog8.

C128 target was added in 7.6 (but very incomplete still).

from prog8.

@FreddyOffenga @zbyti I'd really like to add atari XL support to prog8 but I don't have the time to comb through the materials myself right now.
If you could kickstart it for me by answering the questions in the porting guide (https://prog8.readthedocs.io/en/latest/portingguide.html) it makes things a lot easier for me. Then, once an initial atari XL target is added based on that info , you can start experimenting with it and take it from there.

from prog8.

CPU

1. 6502
2. yes

Memory Map

Zero page

Programs not written in BASIC do not require BASIC to run. On Atari, programs run under DOS (many different variants).

1. $00CB-$00CF unused by BASIC and ASSEMBLER
2. https://atariwiki.org/wiki/Wiki.jsp?page=Memory%20Map
3. $80-$ff without $00D4-$00E5
4. $80-$ff

RAM, ROM, I/O

1. depends on used DOS, most common is $2000-$9fff but ANTIC reserve some memory, depending on the used gfx mode, from RAMTOP to down.
2. not applicable
   3-4. $0600-$bfff if you have in mind DOS, BASIC & ANTIC
3. $a000-$bfff if basic on, generally without HW registers on $dxxx ROM covers RAM from $c000 up.
4. $dxxx look at: https://atariwiki.org/wiki/Wiki.jsp?page=Memory%20Map
5. don't know in details, not used yet.

From here I count on @FreddyOffenga ;)

from prog8.

Does Prog8 support custom targets?

from prog8.

what do you mean with that?

from prog8.

I mean - can i target a 65c02 with a custom memory map and io? for examples /r/beneater

from prog8.

Ah I see. Well, no it doesn't - the target machine's configurations are hardcoded right now. It's not much work to add a new configuration though if you know what's needed.

from prog8.

oh i see. im not really all that familiar with what would be needed and also the languages used. im basically looking for something akin to cc65 customization but with a better C standard.

from prog8.

Well prog8 is not C, so if you're looking for "a better C standard" you're looking in the wrong place.

from prog8.

alternatives to C89 is preferred

from prog8.

Hello, our team is currently evaluating the available technologies for our project. We would like add NES support to prog8, but for that, we would like to know what is the overall process for adding a new target to the language. What files do we have to modify, what is the relevant internal structures of the prog8 compiler, etc.

Btw we will need bank switching, do you think it would be feasible to add to prog8? How do people currently deal with this limitation when they have to bank switch in prog8?

from prog8.

@RealDoigt that is not an easy thing to answer.

Let me first start by saying that prog8 generated code cannot be stored in a ROM, because it uses 'inline' variables and self-modifying code. I am too unfamiliar with the NES to draw any real conclusion here, but I think this could be a deal breaker out of the door?

Then regarding adding a potential new target to the compiler: many of the questions in the "porting guide" linked in the original message, https://prog8.readthedocs.io/en/latest/portingguide.html , have to be answered. This knowledge is then encoded into the compiler and support libraries.

Most notably, in the various target-specific classes inside the CodeCore module, look here https://github.com/irmen/prog8/tree/master/codeCore/src/prog8/code/target

And also most importantly in the syslib library module, look here for the Commander X16 version https://github.com/irmen/prog8/blob/master/compiler/res/prog8lib/cx16/syslib.p8

It's been a while since I added a new target, but the rest of the compiler should be (near) fully agnostic of the target platform. As long as it has a 6502 type cpu

Regarding bank switching: there are no special features in the language or compiler to deal with this. By that I mean that everything related to bank switching is done manually and the compiler has no understanding of it at all.

from prog8.

Yes, that is unfortunate but you are right, not being able to store programs in a rom is a major deal breaker right out of the door.

from prog8.