desertfish

Thanks Stephen, sorry for not searching first. @Hugo4IT: myself is discovering how it all works too. For now I've only discovered how the bitmap graphics modes of the Vera work. I don't have a clue yet about tiles or sprites. This page is helpful although very concise https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md

That's a cool demo @StephenHorn ! But, is there a limit then to what number of the 128 sprites can be displayed on a single line?

(half offtopic: thankfully we don't have to deal with sprite multiplexers anymore as we had on the C64 which only had 8 hardware sprites )

First I've got to get the instruction argument parsing has to work on more than just the trivial cases shown above i.e. first goal is to correctly reassemble a plain disassembly. Dynamic data structures are a pain on the 6502. Maybe it's possible to start with a limited fixed size symbol table to keep it simple initially. Thanks for that document.

I like the 'scrambled' way the image comes up. I wonder how they did the scrambling of the line segments back then rather than drawing it in a natural order

I find it an interesting topic and so I am right now toying around with the first steps of such an assembler .... let's see how far we can take this

Hello and welcome! I guess that you also know about the Vice C64 emulator, for when you want to revisit that Commodore64 goodness?

Exhaustively checking all RAM like in that 'pc bios startup' adds a significant startup delay that should not be there for a machine that was meant to be instantly ready after poweron. But just probing a single address in all 64 possible banks is a really fast way I think to determine how many banks are available... (and just assume the ram isn't bad)

Geos headers? Sorry, I don't follow.

It does seems useful to me but it's more important to (hopefully) get some small bugs ironed out in the rom code that exists now (there are a few pull requests on github already that I think are pretty easy and important to include...)

How does one do this though? As far as I am aware there is no concept of seeking in the Commander X16 DOS routines. So it will mean you'll have to read all required headers into memory and then manipulate them from there as you cannot seek back in the file to read more data from the beginning. What do you mean exactly? There are no ROM routines to do this automatically for you without having to roll your own code

No color cycling

I prefer plain text files as well but mainly because I'm still focused on manipulating them on other systems outside of the Cx16 itself. If we're strictly limiting ourselves to working on the cx16, the benefits of working with plain text files is less clear to me. There are some problems I think with text files as source. - they take up much more memory and disk space than a binary format, so a source listing is quickly larger than the available memory. There is enough banked RAM to load it but dealing with data split up over different banks may complicate processing it as a single file a lot? - text is inherently more complicated and slower to process than a dedicated binary format. Although maybe the 8 mhz can just brute force negate this? - editing can be problematic (naive inserting and deleting requires moving a lot of data around in memory). Although you seem to have solved this admirably in your text editor already !

Something like the Merlin assembler then, Stefan?

I’ve watched many episodes of 8 bit show and tell and Robin mostly uses the Turbo Macro Pro assembler. It provides an integrated editor and assembler. The edit assemble run cycle is really smooth. This is mostly because it can use a Ram expansion/banking to store stuff in and the ability to immediately restart the editor after testing the program. But, I think it allows for assembly to disk as well. Is something like that what you’re after? For the Unix like experience I think I just want to stick to using a cross assembler on pc i wonder if TMPro can be ported

I have to clarify - i meent in the general sense, not actually practically achievable per se with cc65. i asked because I struggled with the same issue for prog8 . Certain types of variables are allocated statically and are not reinitialized at program start but other types are, it’s a trade off , and allows restarting the program if you are careful enough and don’t have to rely on the statically initialized values.

Why is this? It’s a curious restriction. I have an idea why this could be the case but I also think it’s possible to work around it.

highres bitmap mode graphics View File I learned about the various screen modes of the Vera chip. As long as you reduce the number of colors to fit it all in the available video memory, high res 640x480 bitmap images are perfectly possible. 256 colors requires way too much memory though, so for simplicity sake, I reduced it all the way back to 2 colors black and white. Submitter desertfish Submitted 12/27/20 Category Demos  

They''re his images in the first place from what I understood of the description on the web site

To put certain things into perspective, the page just listing all the keywords alone takes up more than 7 kilobyte... It looks to be a very powerful basic (just look at the number of keywords) and from what I see the compiler itself is also written in Freebasic itself. Remarkable.

My mission is complete. You can watch the results in the second demo video that is included in the comment on this topic:

I've updated it with a new version that now can use 320x240 full-screen mode instead of truncated at 200 pixels, and it also can show IFF Color Cycling images to add a sense of animation!! The movie included with the download shows the program running with the included images on the SD card. I found and included a few basic IFF images with color cycling. The real amazing thing is that there are a few extremely high quality color cycling images available to view on-line here http://www.effectgames.com/demos/canvascycle/ as mentioned in the topic here: https://www.commanderx16.com/forum/index.php?/topic/770-new-demo-uploaded-basic-color-cycling-demo/&tab=comments#comment-5197 I've managed to convert these on-line images back into IFF files with color cycling information. Additionally I've halved their resolution to 320x240 (and lost 12 bits of color palette accuracy) but these images can now also be displayed by my image viewer program on the CommanderX16, including their color cycling animation! Unfortunately the images are copyrighted and I think we are not allowed to share them, so instead here is a video of them being displayed on the emulator: ccycle-demo.mp4 It's a pretty long video because there are many images and the loading is not very fast (because they have to be streamed from disk due to being larger than the available memory). A lot of detail is lost because of 12 bit color banding and the resolution reduction (some blending/dithering patterns are wiped out completely), but I still think they are amazing to watch. Watch the video first and then the Effect Games web site link above to admire them in all their original high res detail. You won't be disappointed.

A 2d physics multi-object collision engine on an 8 bit system, that's actually pretty darn nice even though it's not entirely realistic behavior. I always find it fun to play around with anything having physics simulation. It's always more fun when it's less realistic !

While dealing with pointers is still a bit iffy in Prog8. There is however memory mapped variables and the direct memory access operator '@'. &ubyte BGCOL0 = $d021 ; screen color register on the C64 BGCOL0 = 7 ; set color to yellow @($d021) = 7 ; set 7 directly to memory location color = @($d021) ; read value directly from memory location I'm still kinda new at language design, but I find it interesting that we're coming up with more or less the same concept here!