danwinslow

Hi, this looks great. That choice for the default encoding seems odd; I would expect that atascii would be default and screencode would be pragma. Why was that decision made?

Has he released the source code? If the community had that, interested folks could probably team up and make a follow on. Or, better yet, if he wants to be involved still he could guide development. Looks like there is a disassembly project at : https://github.com/jduerstock/ardungeon

Taken. Will re-post if it doesn't work out.

Dang it, I knew I was forgetting something Omaha, Ne, 68133

About 150-200 disks. Weight likely around 8-9 pounds ( 4 kilos-ish ). No list, no pictures. Looking to send them to a good home with minimum work on my part. From quick visual inspection, some good stuff in there, also some usual standard setup disks for various systems and some cracks and home made stuff. First to PM and follow through gets it for shipping. Also some games and manuals, which I can exclude for weight if desired. The manuals will add weight, they are mostly just the game manuals so pretty thin but still.

This is taken, thanks.

Hi Folks - I have about 150 or so old assorted 8-bit disks. Not going to make a list, but if anyone wants them PM me with address. *Note - I'm in the U.S. I'm just asking shipping, otherwise they are free. Not tested.

I agree with Irgendwer. The level of nitpicking from people not directly contributing is surprising to me on the board, and I've seen it in many efforts, including my own a while back. I have to say, it did contribute to my eventual dropping of the project, although it wasn't the primary reason. Just focus on what you think is best, rensoup. They have the option to not play the game if they don't like it, or to write their own. I advise against flicker as well, though since you did ask for opinions.

I will buy 2.

Not letting perfection be the enemy of good is probably a thing here. Getting the game itself working is probably paramount, and non-amazing opening screens can be fixed later if desired.

Did you try the forms that draco suggested before or after your original attempt? If you tried them after the original attempt, then as draco says it was already munged at that point so errors would not be surprising. If you tried them before what you originally posted then, also, it was already munged but means that your original attempts did not cause the problem.

yeah, I had 3.10, which crashed. 3.20 works great, thanks. Looks like a really great game.

Way late to the party, so forgive me...but the latest download from the first post crashes in Altirra with an illegal instruction. I have Altirra set for a stock 130xe, PAL.

Lol, that's putting it mildly. You guys collectively know more about the computers than the original devs did.

I was kind of joking, and referring to his statement that there's not going to be an Atari renaissance. That's true enough, but doing stuff like this is fun and who knows, it could keep going for quite a while. My grandson is kind of into it - he says that the graphics are weird but the games are fun. I am giving him a 130xe for his 10th birthday and teaching him to program in BASIC as kind of an introduction to computers. It's perfect for that...its kind of like giving your kid a lawnmower or a volkswagon beetle or something to learn engine repair on- it's simple enough that it's easy to learn but complex enough that you can really do some cool stuff. I think the community here is great and there have been some really amazingly good stuff done. It's definitely not pointless, but it is true that it's going to remain kind of a niche thing. And now, back to the thread topic...

Stop making sense, Alfred. People hate that. I know how Thom feels, though, having tried a similar thing myself. It is frustrating.

Well, having a linker like CL65 adds a kind of abstraction that gives you a lot more control over what's actually happening. You can separate the concerns of the source code itself from the concerns around segments and what's where and what type it is. Is it necessary? No. Is it handy? Yes.

No fair - this is about BASIC

Well, I never got that sense of amazing possibility from a post-it note that I did from my Sinclair. Anything seemed possible with the little computer, on the post it note I could...uh, write some stuff...like a grocery list or something. With the ZX I could explore vast reaches of space-time using only my brain and that horrible f'ing keyboard. A reasonable price to pay.

Why does it matter whether it uses for next loops? Just wondering. If what you really mean is 'it needs to be faster' there's probably more than that which could be done.

Very nice stuff, Ilmenit. I learned a lot from you over the years. In particular, I wrote an (atari st) mouse handler for the A8 completely in CC65, using your techniques. It was an interrupt handler off of one of the pokey timers, and worked great.

Hi Jon. Yep, that was almost exactly my method, although I did not extend it to 16, although I think I meant to. Copying 64 bytes back in each context switch is a little slow, but having it check if it has residency already is a nice touch.

For one small threading experiment I divided the stack page into 4 separate stacks, and implemented a 'stack frame push/pop' scheme so that I had 4 separate 'pseudo-threads' running at the same time. I actually did some of it in CC65, I think, dropping into assembler. I'd have to look it up. Was pretty cool, but at first was not preemptive and the threads had to do yield. I looked into making it preemptive using an interrupt, and that worked...sort of. Pretty much crashed anytime I tried to do any OS or DOS calls, of course, and that wasn't surprising, but I could do simple things like increment a counter. I did get some screen IO working but I had to devote 1 thread to being the only one doing it.

Hehe. I think OP was just trying to ask if there were any other (simple) solutions to going through the push/pop dance. This really wasn't about stack manipulation. So, I think the the answer is no, there are no other simple solutions. There are many ways to save and restore the reqs, but they all involve some variation of individual storing and loading. Also, OP mentioned reentrancy, and if you want to be reentrant, you have to have a stack somewhere even it's one you wrote yourself.

If you want to be reentrant, you have to have a stack somewhere. I don't think that when writing for this machine reentrancy is usually a major problem. As far as I know, there are no other solutions, you must either store on the stack or in some other location. You can directly read the values off of the stack by using the SP, but then you wind up having to either adjust the SP manually or pull then anyway. Loading directly via lda,ldx,ldy of course works.