Opening a dialogue for SpartaDOS Source Code

[Opening a dialogue for SpartaDOS Source Code]

32 minutes ago, Alfred said:

To the other guy, why bother with GitHub. All the other source code is on Carsten's wiki, which seems good enough. Why not just keep posting stuff there, and people can copy it to whatever library manager they use.

 

Because I am talking about a larger effort, not just about the specific code you are talking about.

[Atari 1400XL Lives!]

39 minutes ago, Mclaneinc said:

 

Excellent Dan, I think its HUGE ask for it to be added to Altirra and as they are proto's there may be no enthusiasm to add it. Altirra has always (for me) being about an out of the retail box idea.

 

Would it be cool, hell yes but I doubt if its ever been on Avery's busy list...

Oh of course. Avery can hold his own- I doubt the steady pressure of my steely gaze would have any effect if he didn't want to do so on his own  Twas just a suggestion.

[Atari 1400XL Lives!]

Maybe we do....

 

[Atari 1400XL Lives!]

On 5/10/2021 at 6:56 AM, Allan said:

I mean something that the 1400XL OS would detect as the internal 1400XL Votrax chip but have it on cartridge. Of course finding a Votrax SC-01 would be tricky. But you would have a better chance of finding a SC-01 than a 1400XL.

Do we have the OS dumped out anywhere? Maybe @phaeron would add 1400XL as an Altirra emulation.....

[Opening a dialogue for SpartaDOS Source Code]

Well, we carefully preserve, archive and organize the software products and games. Why doesn't someone start a similar github - "The Atari Source Code Preservation Project" so to speak. Then people can donate source code to it for items of mainline interest as are being discussed here. Then we don't have to remember if person x has source code y and hope they are still alive.

[1400XL value...]

13 minutes ago, Justin Payne said:

I can't predict the future but I don't see this retro fervor lasting forever and I suspect this is around one of the best times to sell something like this to get the best price possible. Could the value go up? Sure, but as those who grew up with stuff like this, there is a point where they retire and interesting in having a collection might not be as important so might as well sell it while there is interest from the community.

I think this is correct. And, that's a beautiful system.

[Franny: error compiling]

3 hours ago, Harry Potter said:

I don't know, and no.  Sorry.  

It would be unusual to not be able to use GCC. What OS are you on? If you are on windows, you should be able to use MinGW: http://mingw-w64.org/doku.php

 

[Programming Experiences]

When the C code is written correctly, CC65 is a very powerful platform that also allows really good integration with assembly and control over memory layout. By 'correctly' I mean 'not like a usual C program'. See ilmenit's tutorials on this site. You do get some benefits from being 1 step up from bare assembler, but as mentioned it's still going to be pretty technical. It has to be.

 

 

 

 

[The best video to HDMI converter]

I'm not qualified to say, exactly, but I've read in threads here that Atari skimped on components and/or didn't do something right on some models. That and interference from the memory operations, etc. Maybe RF is just inherently noisier and lower quality too, not sure.

[The best video to HDMI converter]

the signal from the RF is crappy to start with, at least in my experience with NTSC ataris. You can get converters, I think, but they will just show you the fuzz and lines in the original signals at a much higher resolution.

[Mandelbrot Explorer in 10 lines of Atari BASIC]

Wow, that's cool. Amazing. How long does it take to render?

[PLOT and DRAWTO with CC65 in C? [solved]]

I misunderstood then. Missed the linking *

[PLOT and DRAWTO with CC65 in C? [solved]]

3 hours ago, Wrathchild said:

By 'thread' I would more say:

If you look at '.proc LINE' in the tgi drivers then as USE_CIO_LINE isn't typically^* used they will be using the Bresenham's implementation in there.

https://github.com/cc65/cc65/blob/master/libsrc/atari/tgi/atari_tgi_common.inc

 

^* - though has been mentioned here by @sanny

 

Not the wiki about bresenhams. The above is what I meant, although I don't see where Sanny mentioned it. I'll take your word for it.

[Backplane Atari Computer]

Looks great.

[PLOT and DRAWTO with CC65 in C? [solved]]

Nice. I recall an old thread about the fastest line drawing algorithm that also had code examples, but I can't find it before my ADHD kicks in.

[PLOT and DRAWTO with CC65 in C? [solved]]

https://atariwiki.org/wiki/Wiki.jsp?page=3dMaze

If TGI is performant enough, that'd sure work.

 

[PLOT and DRAWTO with CC65 in C? [solved]]

The TGI support for CC65 isn't the greatest as I recall (although it may have been updated since I last saw it). I can't remember if there's OS support for plot and drawto, but I think not, and that probably wouldn't be the fastest either.

I always plotted directly by writing to screen memory, and for drawto I dropped in a fast line algorithm. You can find them in asm or native C with a bit of googling or searching here.

 

*edit*

Actually, I think I recall that there are some graphic libraries that other people have done that you could find.

[Playfield graphics when ANTIC off]

3 minutes ago, playermissile said:

I'm doing some reverse engineering of a game that uses a 2600-style kernel with ANTIC turned off. No display list! It's freaky. Anyway, is the only way to generate graphics through using writes to GRAFP[0-3] and GRAFM? So there is no way to generate playfield graphics (like the PF[0-2] registers on the 2600) through direct writes somewhere? I don't see anything obvious in Mapping the Atari, but I've never dealt with a kernel before.

You can always write to screen memory? If I understand your point correctly.

[A new language for the Atari]

18 minutes ago, Kaj de Vos said:

Anyway, I heard nobody wants a safe language on 8-bit, so it's all fine, isn't it?

Mad Pascal is probably the closest, although if you mean 'safe' to include no pointers, then not it either. Safety usually costs some amount of either complexity, speed or memory. The 8 bit is so constrained it's usually not worth it. Java can tell you that 'no pointers' by itself does not equal safe. I come from an Ada background, a famously 'safe' language, and programmers generally hated it because of what it wouldn't let you do. It happens to still be my favorite language, but nowadays everybody uses Javascript, which I don't event consider a full language and is so bizarrely unsafe it reminds me of C, although at least C has a coherent syntax. Ah, progress.

[FastBasic 4.5 testing release]

4 hours ago, funkheld said:

i find the programs boring.
There is no connection to the outside with rs232 or tcp.

In fact, there is nothing fundamentally new, but rather small defects are always eliminated that are actually not noticeable.

 

the fresh wind with rs232 and tcp is missing

greeting

Funk - I find your complaining boring. The world is not about you. If you don't like this language, then just don't post. If it's no good, it will die on it's own.

Why don't YOU bring this 'fresh wind'? You can do do at least little programs.

 

greeting

[A new language for the Atari]

9 hours ago, dmsc said:

Hi!

 

IMHO, the setting of LMARGIN this should be discussed in the CC65 issua tracker  . 

 

Have Fun!

i agree.

[Sophia 2 preorder thread]

Me too. 1 for me.

 

Thanks

 

[Attempting to make a Colorview (4096 color) viewer in cc65; Help Wanted]

you don't need to type it all those embedded asm() calls just because you need the variable linkages. You can see C symbols just fine in your .s files, just do the correct externs and .imports. That said, sounds like pps might be on to something.

 

[Backplane Atari Computer]

Nice!

[AtaSimpleIO/cc65 doesn't work.]

1 hour ago, Harry Potter said:

I thank you for your input.  My SimpleIO libraries are meant to save code by calling the OS directly with minimal extra work.  It's not necessary for most purposes.  I will stop working on it.

Please don't quit on my opinion - I am often wrong  If you are trying to save code space rather than execution time, then yeah maybe it's not needed. But if you want to use your simple_io as a basis to work in a familiar environment or convert something that is written to use those calls, then setting them up to call the CIO handlers won't really add much code, and you can probably reduce the code space used by conio.h functions somewhat by setting up your own, specifically optimized, CIO calls.