[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.

[AtaSimpleIO/cc65 doesn't work.]

You commented out your store of the printc jmp address in crt0.s, so now you have a JMP $0000 in there which is definitely going to be an issue. Looks like you were trying to jmp to the address in $E406 with a 1 added to it (?), which I guess is some kind of E: handler entry point, and the same thing for $E414. You don't have to do it like that, you could set printc up in C as a function pointer and set the address at that time, or just drop into ASM and jmp yourself, look at the options for the asm() function to see how to get symbol addresses/values into your asm statement. Your C program will start directly after crts0.s jsr to your main, so you can put any initialization you like there rather than messing with crt0.s itself.

 

Let me just say I think (if I understand) what your seem to be trying to do is probably not a great idea...if you are trying to jump around the CIO handlers by directly calling OS routines to save time, then (a) it's likely to cause problems, and (b) not sure you'll save all that much time. If you want REALLY fast screen writes then write your own code to do direct screen memory writes, or better yet wrap the conio.h calls in your functions, those are already pretty fast. Looks like you are moving a library from a commodore version, but Atari, generally speaking, you don't want to skip handlers and directly call OS functions, they were mostly all designed to be called by handlers or by the OS itself. 

[AtaSimpleIO/cc65 doesn't work.]

13 hours ago, Harry Potter said:

I changed the crt0.s file but disabled the change.  Sorry about the repeat!  And if you mean the header file, I attached it here.

simpleio.h 2.25 kB · 4 downloads

Yeah, don't mess with the crt0.s file unless you really know what you're doing. Not implying you don't, just saying it's dangerous.

[AtaSimpleIO/cc65 doesn't work.]

Much more likely that he's crashed Altirra the old fashioned way. But yeah, grab the latest altirra.

 

HP, that's the standard crt0.s from CC65.  Did you change it?

 

What's in your simple_io.c file?

[Fine Horizontal Scrolling in BASIC Explained]

Wow, that's great stuff!

[FastBasic 4.5 testing release]

3 hours ago, dmsc said:

Hi!

Not necessarily, you can share CC65 libraries (.lib) or object code (.o). Currently the FastBasic cross compiler distributes all it's libraries as one ".lib" with all the compiled code. The CC65 object code and libraries are fully relocatable.

 

Have Fun!

They are? Has CC65 changed drastically lately? Not sure what I'm missing here, but I had to write my own relocation routines to load externally created .o files at runtime, even when created using CA65. You seem to be saying it will all be compiled/linked together, which of course will 'relocate' it. I was talking about a dynamic linking system, such as .dll or .so. At any rate, I'm out, because I don't understand what either of you guys are actually talking about. Love FB though.

[FastBasic 4.5 testing release]

So you meant FB source code in separate files like include files?

[FastBasic 4.5 testing release]

Ah that's cool. But I think he meant like separately developed object libraries. With the way you describe above, you would just have to share appropriately coded source instead of a precompiled object file.

[FastBasic 4.5 testing release]

yeah, I think a way to bring object code libraries in and call named entry points would be handy....one thing, though, wouldn't relocation have to be handled? Either relocation or some sized area would have to be set aside I would think.

 

Relocation is not all that hard, FB could specify a load format (obj prefaced with a relocation table, for instance). Actually I suppose a symbol table would be handy too, just like a real .dll or .so.

So It'd be something like:

 

[relocation table]

[symbol table]

[object code]