Search the Community
Showing results for tags 'SpartaDos X'.
-
Greetings and felicitations, children of technology! A few of you may know me from around three decades back. I have to congratulate you all on this cool forum, that has amazing activity. I am happy that the community is still there. I am contacting the community again, because I am doing some work on Atari again. I am making a new programming language, that will be general-purpose, but that I am targeting at 8-bit Atari first. Most new languages don't target the old machines. There are a few exceptions, but they target the vintage machines specifically, and are not meant as general-purpose languages for modern systems. I think this is feeble and probably wrong in terms of language design: there are many bad reasons, but no good reason to not support small systems. C is still used everywhere, and it can do it. I think any new language should improve on C; it should not be less capable. I always thought this should be possible, and it is turning out to be true. At first I thought it would be harder to support the old systems, but it actually turned out to be easier, and it helped get the project off the ground. Small systems are much easier to work for due to less complexity, they are more motivating, they provide meaningful results earlier, they keep you aware of performance and they prove you can target very small devices, such as for Internet of Things. Like how Contiki became an IoT operating system starting on C64. I have wanted to do this language for some three decades, but the industry became ever more complex faster than I could master it. Every time I thought I could improve some things, the platform I was using was already outdated. For a quarter century, I didn't really know how to improve languages on the newest platforms, so I tried to use the best ones I could find. Yet almost every time I wanted to do a project or a commercial assignment and needed the platform and language to just work, I ran into walls that debilitated my efforts. This was all the more frustrating because there once was a system that I could do anything on that I wanted: my trusty Atari 8-bit. Perhaps my projects are too ambitious, yet this was no problem on Atari. I desperately need that power and control back, and in the past years, the puzzle pieces started to come together. Now it's a matter of doing the enormous amount of work required from a modern language. I am half a year into the project, and am double as productive as I have ever been. The language is mostly inspired by REBOL, of Amiga heritage: https://en.m.wikipedia.org/wiki/Rebol REBOL has great clarity and conciseness of expression, and a great capacity for abstraction, which can be used to define cross-platform abstractions. It has been measured to be the most expressive general-purpose programming language: https://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/ Among others, I was further inspired, for their performance and support of native Atari functionality, by Action!: https://en.m.wikipedia.org/wiki/Action!_(programming_language) and by PL65: https://atariwiki.org/wiki/Wiki.jsp?page=PL65 The language is past the proof-of-concept stage, but it is still very incomplete. On the other hand, it will match features expected from an 8-bit language before it will be able to match expectations for a modern language. I am working on a sneak preview release to let people try it. I will post examples as I go, if you like. After the sneak preview I will be working further on a crowd-funding website, where you will be able to influence the development through donations.
- 252 replies
-
- 12
-
- programming language
- compiler
- (and 7 more)
-
Previous program here My new programming language now has an extra backend that generates 6502 machine code directly, without generating C and going through CC65. One of the benefits is that I have been able to implement the special, relocatable program format of SpartaDOS X. Here is the Rainbow demo that I posted earlier, now compiled for SDX: https://language.meta.frl/examples/platforms/Atari/8-bit/SpartaDOS-X/RAINBOW.COM The program file is only 29 bytes. SpartaDOS X loads it wherever MEMLO happens to be and runs it from there. The program code is here: The new backend produces simple listings of the generated code, which are mostly its internal data structures: https://language.meta.frl/examples/platforms/Atari/8-bit/SpartaDOS-X/rainbow.list The backend doesn't support as much of the language yet as the CC65 backend. This is a lot of work and will happen over time. I believe this is the first compiled programming language that supports SpartaDOS X, beyond assembler and the interpreted SDX batch language. I am very happy how it is turning out. It's the fulfilment of everything I wanted to do three decades ago. ?
-
@santosp Current Turbo Freezer 2011 Production - Declare Interest Thread @HiassofT Turbo Freezer 2011 - Original Production Thread @HiassofT Turbo Freezer 2005 / 2011 - Files @ndary Turbo Freezer 2011 - Demonstration Video I finally had a chance this last weekend to test out my new Turbo Freezer 2011 from @santosp. Great device and great implementation. The YouTube video by @ndary was a good starting point for understanding how to use a lot of features in the device. But after I started delving into the manual and seeing some of the other features, I had a few questions about how some of the features worked together and what would be some of the best ways to utilize some of the features. After going through the manual and testing a few things out, I decided to make up a memory layout overview, to help visualize what I was working with a little better. Turbo Freezer 2011 - Memory Layout Flash ROM (1 MB - 128 x 8 KB Banks - 16 x 64 KB Blocks) ------------------------------------------------------- Banks 000 - 119 (960 KB) Cartridge Emulation Banks 120 - 127 (64 KB) Freezer Software (+ Cart Emu Menu & Oldrunner OS) Battery-Backed RAM #1 (512 KB - 64 x 8 KB Banks - 8 x 64 KB Blocks) ------------------------------------------------------------------- Banks 000 - 047 (384 KB) Cartridge Emulation Banks 048 - 055 (64 KB) Snapshots (Optionally: Cartridge Emulation) Banks 056 - 063 (64 KB) Freezer Software Battery-Backed RAM #2 (512 KB - 64 x 8 KB Banks - 8 x 64 KB Blocks) ------------------------------------------------------------------- Banks 000 - 063 (512 KB) Extended RAM / RAMDisk In terms of usage, what I decided to do for the cartridge emulation portions was to make a 960 KB AtariMax ROM filled with games and put that in the flash ROM area; and then put SpartaDOS X + several OSS carts in the Battery-Backed RAM cart emulation area. This provides a nice setup of games and development/DOS. Using an Atarimax ROM for filling the cartridge emulation ROM with games works out nice, because you only need to flash a single ROM to add all the games you want; and you can put both ROM's and XEX files into the Atarimax ROM; plus you get the easy to use Atarimax menu (which can use joystick or keyboard) for selecting from your games (or whatever else you might want to have loaded into the ROM). A nice feature for SpartaDOS X is that the Turbo Freezer can simulate having a second cart piggybacked, giving simultaneous access to SpartaDOS X and Mac/65 (for instance). One thing to note here for those just starting out using the Freezer, is that the extended RAM / RAMDisk area is both of those at the same time and neither has any regard for the other. This means you could overwrite some snapshots in the RAMDisk area by loading a program that uses the extend RAM or, visa versa, you could overwrite something in extended RAM by storing a snapshot in that area of extended RAM being used. One thing to consider in this regard is that not all (not many) programs use 512 KB of extended memory. So, saving snapshots to higher RAM can allow you to preserve both without having any conflict.
- 18 replies
-
- 10
-
- extended ram
- cartridge emulation
-
(and 3 more)
Tagged with:
-
I'm looking for a couple of utility disks that don't seem to be in any of the archives. QuickCode is a set of macros for use with Mac/65: QuickCode - Atarimania FlashBack is a backup program for use with SpartaDOS: FlashBack - Atarimania Info for both can also be found here: Antic Reviews - Power Tools If anybody has an ATR of either of these to share, or has a real copy and would be so kind as to make an image, it would be greatly appreciated. Thanks, MF
-
Hello everybody, am trying to figure out the best way to do SDX system calls from C via cc65? For example, there is a routine that can be called to get the current date and time: void timedate(TimeDate* td) { struct regs r; assert(td!=NULL); r.pc = 0x703; // KERNEL r.y = 100; // GETTD *(byte*) 0x0761 = 0x10; // DEVICE _sys(&r); // Do Kernel Call. td->day = *(byte*) 0x77B; td->month = *(byte*) 0x77C; td->year = *(byte*) 0x77D; td->hours = *(byte*) 0x77E; td->minutes = *(byte*) 0x77F; td->seconds = *(byte*) 0x780; return; } Is it possible to use a similar mechanism to get access to the other SpartaDOS X functions? For example, I need to be able to set errno, when one module of my program goes byebye, so that I can call the next program module to load (and to cut down on footprint. I do not want to write a whole overlay system when I can use the OS to do it reliably). What I _want_ to do is have an overreaching TSR program (which I'd LIKE to be able to write in C), which will provide serial routines that I can call (open, close, read, write) from the other system modules (LOGIN.COM, BULLETIN, MSGBOARD, FILBOARD, BYE, etc.) and thus not only keep the memory footprint down, but to maximize modularity/flexibility. -Thom
- 5 replies
-
- 1
-
- SpartaDOS X
- System Calls
-
(and 1 more)
Tagged with:
-
If you look at the TDLINE display, you'll notice that it shows an 'a' for AM, whereas the file 'DATA_IN.BAS' which was saved only a few minutes earlier has a time stamp of 12:39P (which is correct). At 1PM the TDLINE display will change to a 'p' for PM as it should be. Everything else works properly, and the date will change at midnight as it is suppose to. Anyone else have this problem? Or is it just me? Has this been fixed in the latest release? - Michael
-
I hope it is appropriate to post "for sale" items. Cleaning out the attic, and selling some old Atari 8-bit stuff on Ebay. I was a big Atari geek back in the day, I'd like to see this stuff go to somebody who will appreciate it, instead of the landfill. SpartaDOS X cartridge with SpartDOS Toolkit disk. www.ebay.com/itm/301844912080 Original Atari literature, lot of 5 pieces: (1200XL users guide, 1982 Atari Product Catalog, etc) http://www.ebay.com/itm/301844916921 I'm also selling some Atari ST stuff, if you are interested check out my ebay user page: http://www.ebay.com/usr/chris82369
- 1 reply
-
- spartados
- spartadosx
-
(and 8 more)
Tagged with:
-
Good morning. I've been exploring SpartaDOS X within u1mb and am really enjoying it. I've encountered my first problem though: I can't format disks. I typed in the FORMAT command, which brings up the super intuitive format menu. Whether I select SpartaDOS or Atari format, single or enhanced density, the computer crashes when it tries to verify the format. I have tried this on two different 1050s, with both the same and different disks and have experienced the same result. Both of these 1050s format with DOS 2.5 just fine. Any thoughts? Screen shot below of the SpartaDOS screen disposition once things go south. Again, it appears to format and then crashes when it tries to verify the format.
- 3 replies
-
- SpartaDos X
- 1050
-
(and 1 more)
Tagged with:
-
Hi guys, Am trying to read the Spartados X Programming Manual, but it's in Polish, so... I just need data on talking to the "get time/date" vector in SDX, and what format the data is in, so I can write real time clock routines, for inclusion in BB65. -Thom
-
Does anyone know of a reference which explains how command-line arguments are passed to ".COM" style XEXes in DOS XL (and presumably SDX as well)? I'm given to understand that both DOSes use a similar mechanism but I can't seem to find any information about how to write an XEX that accepts arguments. I'm near to disassembling .COMs at this point.