Dave C
-
Posts
110 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by Dave C
-
-
Long time since I first posted this - on an endless series of side quests around my Refhraktor and "VCS Lisp Programming" projects...
Anyhoo... I've gone back and reworked my previous run at TIA export for furnace. The new export has been updated to mirror changes to the main code base, does a little more aggressive compression, ... and I made the default player "nicer" graphically. I'm hoping to work with the furnace committer(s) to keep this moving forward... (I just need a TIA export option - I don't need it to be "my" ROM export)
https://github.com/tildearrow/furnace/pull/1555
Attached a sample from the furnace demos (Atari Breakbeat)...
-
1
-
-
This is all really a bet on what is going to save you time. Will you only have to do this once and never change the data? one time cut and paste from excel seems like you are already done - time to move on…
Do you need to repeat the process over and over? At that point you maybe want to write a script so you can separate the data from the code.
But using data to write code and vice versa is what it’s all about - how you do it is up to you… for me I adopted python a while back for this kind of thing because for me it was a pretty easy jump from the languages I already used (basically, a better Perl) but I wouldn’t blink if I saw someone using something else
-
1
-
-
+1 for python for this sort of thing
-
On 9/17/2023 at 1:54 PM, Aloan said:
I always had it to me that the backgound is indeed its own thing, even though all we can do with it is change its color on each scanline.
Well it doesn’t for instance have collision detection or a location. You can change the background color mid scan line if you have spare cycles and can commit to racing the beam but it’s definitely a pricey trade off
-
On 7/24/2023 at 9:11 AM, Mr SQL said:
Check out this algorithm that became a ring tone.
That sort of thing is perfect. And it’s even in BASIC
-
On 7/23/2023 at 6:14 PM, ZeroPage Homebrew said:
EDIT: FOUND THE FRAME JUMP, it's at 1:55:46 and I even mention it during the stream. It just as I remembered, it's when the big fly comes in on the right hand side and takes a bite of the banana.
First off - I can't tell if this whole quitting thing is just normal frustration - which - we all have, or hyperbole, or something darker. If this is something other than just normal coding frustration - honestly take a break.
But when it's time to pick things back up..
On fly27.bin, I was able to repro after hacking the score (to speed up the process)- There is variable for $82 = OverscanValue that controls a loop that waits through the overscan period. It normally has the value 10, gets written with a value of 15 for just one frame and that causes the wait to take one more scan line (using the timer)
- I haven't read enough of the code to know what different overscan values compensate for - and counting the cycles is not fun (I do it though...). I also can't repro on fly29.asm.
Tbh I'm not sure about the advice I'd give here.
As far as I can tell the overscan loop gets hit in exactly the same scan line at the same cycle every frame- correction: the overscan loop appears to be hit on the same scanline every frame +/- a few cycles. If it's always the same scanline the good news would be the overscan doesn't need the variable timer, it can just skip a constant number of lines - which would save on modifying the overscan var and checking the timer.-
4
-
7 hours ago, Karl G said:
I wasn't able to reproduce the frame jump when I tried, even when swatting near the banana. Is there a reliable way to reproduce this issue?
I didn't notice it either. A tip I learned from the forums, Stella (maybe other emulators) lets you set a trap on number of scanlines, makes this kind of thing way easier to debug.
-
7 hours ago, Mr SQL said:
How much RAM is available for the tiny LISP program?
You can have a program of up to 32 cells - each cell is 2 bytes and is either a number (3 digit BCD) or a pair (aka a cons cell). It's just enough to express the fibonacci program with a little to spare.
For comparison,- the IBM 704 (where LISP was first implemented) apparently had 18kb of magnetic core memory (4096 36-bit words) and 36kb of magnetic drum. And cost something like $2MM dollars and required maintenance every 8 hours.
- I've recently become aware of SectorLisp, which implements LISP in 436 bytes of an IBM PC boot sector. So depending on how the 8088 instruction set compares to the 6502 I might have some opportunities to do better on ROM - if you take away display, the evaluator + basic functionality part of VCS Lisp code clocks in at 640 bytes (348 bytes for the evaluator, 292 for math functions, etc).
I'm thinking about a few mini games to try and round things out:- towers of hanoi
- tweetmaze
- Mastermind?
- some way to create graphics (since BASIC programming had a way to program a primitive paddle game feel like I should check the box on that)
- something with sound (since BASIC programming let you play notes). The current version does have a "note" function that will play a sound.
-
2
-
14 hours ago, waynel said:
I envision some awesome overlays for the BASIC Programming keypads.
So important question:is it disappointing if I don’t plan to have keyboard support? the code currently is hard wired for joystick only - I thought it would be more accessible for users that are used to joystick / don’t have them (myself included). But not sure it’s feasible to evolve it to the point where you can just pick up and play without some reading, and maybe the keyboard would be just as easy to use?
-
Rather than indirect jump you can also push the address you want to jump to onto the stack then rts. This is one of the techniques used in bank switching. It is a simple idea that I found mind blowing coming from higher level languages because you just get so used to thinking about returning to your caller not returning to something you want to call.
I have some more recent code that does primitive multitasking. There are various routines that may not complete before the vblank routine ends so I have them all periodically jsr to a routine called “wait” that ensures we preserve the stack and jumps back to the rest of the code base so we can draw the screen, etc. Then I have a “continue” routine that does an rts back to the address we waited from. I am 1000% certain these are not novel techniques.
-
cool I definitely like the addition.
I do have a few more thoughts - just my 2c- most important - I think the game should always start with flies (or at least the first game).
- less important - big flies sooner - maybe every 100? and take lots of hits kind of like fighting a boss, then a speed jump. but that might just be me being bad at the game and having a hard time getting to 200.
- bonus - if hornet/bee just flies in and tries to keep me from banana - that would actually be a way to be extra aggravating (harder to get to the next flies)
-
2 hours ago, utz said:
This is completely and utterly insane. I love it.
That is exactly the reaction I was hoping to elicit.
Evaluation is radically simplified by not having closures, lambda breaks that assumption. Looking for a good target program for cons. I'd really like some kind of search. It just has to be able to stay inside the 32 cell heap limit...
Before I can move forward on any of that I probably have to reorganize the display and editing kernels. I feel obliged to stay inside 4K, and they take tons of space and are overall ridiculously hairy.-
1
-
-
3 hours ago, glurk said:
There are actually TONS of optimizations possible.
What glurk said - 2k optimization is an art form in and of itself.
-
Just tried it, very satisfying to swat the flies. I really like those fly animations and I like seeing a 2K game with lots of color.
I really want a way to fight the hornets and bees.. or maybe an enemy like an ant that crawls on the ground... or even a double size fly I have to swat twice..
...but those 6 bytes in a 2k game... so much easier to go 4k but would be so much cooler to stay 2k...
I don't mean to pry but my "scan for ways to get more bytes" OCD is triggered because I just went through one of my own projects that is running into the 4k barrier... way easier than 2k..- The font looks like it might be big. But it's really good looking. But it's big...
- I see maybe a few places where there *might* be chance for simple code size optimization - things like, if I did a load, I know it sets comparison registers so i can avoid a cmp #0 and get a couple bytes back - but if the changes I want to make need that to be a cmp #1...
-
These jsr sequences differ by one jsr... if you were willing to intermix the two routines you could put the label for F959 at F943 and they'd act the same... 22 bytes isn't a ton but maybe enough to make a double size fly?
- and then there's... depending on if they aren't called more than once... if you can just inline the code being jsr'ed you save a few bytes + not having to jsr and rts back...
-
Thanks for checking it out!
5 hours ago, JetSetIlly said:what is the correct form if I want to use the result of "+ 1 2" to multiply by 3?
So the steps to get there look something like this:
-> 
->
-> 
-> 
Basically, in prefix notation this would look like (* 3 (+ 1 2)) but the editor has no way to say "insert (* 3 in front of (+ 1 2)" - so instead you have to rewrite everything by changing the + to *, the 1 to a 3, the 2 to + ... at which point the editor starts a subexpression and starts a new line.. and so eventually you can get there.
-
1
-
-
UPDATE 2023-07-16: Play the game on Javatari.org, and check out the latest code on GitHub!
I've been on a bit of a side quest with this WIP... This is the first public alpha, very interested in feedback. I have tested on Stella and Javatari - there are definitely graphical glitches...
This WIP is from an alternate reality.- where a computer language from 1960
- is hastily crammed onto a ROM cartridge in 1977
- so you can learn to write programs of the type you find in the first chapter of a textbook published in 1984.
It is not a competitor to Basic Programming but I am definitely trying to think in terms of the feature set and capture the spirit of a "programming game".
Some screenshots...
Some concept art courtesy of DALL-E mini because why not...
InstructionsProbably some explanations are needed.
The basics:
- The main screen is the REPL (read-eval-print-loop). It is preloaded with an expression (+ 1 2) represented as a boxy array of cells.
- Moving the joystick up to EVAL and pressing the fire button will evaluate the expression and you will see the result
- Pressing the fire button on the +, 1, or 2 cells lets you change the function and the arguments being applied.
- Pressing the fire button on the ∴ lets you extend the expression (note (+ 1 2 3) will *ignore* the 3 right now)
-
Pressing the fire button to select the +, -, *, / ... symbols will start a subexpression
- Note when you create a subexpression (or make a list longer than 5 entries) the display will shift to display the containing expression vertically
-
The 0...9 symbols can be used for small numbers, if you press the # symbol you can input any number up to 999
The fun (as in functional) part:
- If you move up to "EVAL" and press right you will cycle through various function definitions that can be called from EVAL...
-
Functions can be named anything you want! As long as the name is one character long and is either a λ,
, or this funky looking f
- I hope you get the picture: there are no strings and there are 3 bytes reserved for pointers to functions. You want more? Source code forthcoming, feel free...
- Arguments to functions can be anything you want! As long as the first argument is a, the second is b...
-
For maximum fun I've loaded a few predefined functions
- λ: starts as (* a a) - if you EVAL (λ 5) you will get 25
-
: takes one argument (a) and calls the funky f...
-
funky f: this is the fibonacci function, which is a recursively defined function f(n) = f(n-1) + f(n - 2)...
- ... to be specific this is the tail recursive variant - and - if you've read this far and see where we're going - yes this LISP has some super simple tail recursion optimization (otherwise we'd blow up the stack very quickly)
Some known issues
- since I preloaded a bunch of functions - there actually isn't a lot of room left for editing new programs unless you wipe the predefined functions
- The REPL will attempt to stop you from blowing up the heap writing programs but I'm sure there are holes
- The EVAL will attempt to detect stack overflow before you overwrite critical RAM, but it's not a flawless check
- Really complex expressions can take too long to "parse" for display and that will mess with vblank...
-
Division function not implemented
- thinking about it...
-
No lambda, cons...
- thinking about it...
Implementation TLDR:
Borrowing from PicoLisp, the only data structure is a 2 byte cell that represents either a pair or a number. Evaluator based heavily on Chez Scheme, and I'm looking at uLisp and Basic Programming for ideas for sample programs and games...
-
16
-
1
-
If you had the cycles to use an asymmetric playfield - you could make the change at points where the transition is clean but you'd need to do something about the whole image being off center (like put a black missile down one edge)..?
In some work I've been doing I've been playing around with making background color transitions at CPU cycle 28 (16) and cycle 71 (145). I'm using graphics in PF0 to at least partially cover over the transition area.
As things look whole screen.
Here is cycle 71, the overlap is definitely visible (although some color combinations make it less obvious).
-
3 hours ago, lucienEn said:
it can automatically figure best way to efficiently split up in zones including how many kernel scanlines per object.
So is there a way you identify which sprites (objects) can move where? essentially deciding the ranges of vertical and horizontal motion determines when and where you would potentially need to reposition a sprite (unless you use a multisprite kernel like bb in which case you use one big zone for everything)
-
I use the background builder a lot but for sure I wind up using it to create mock-ups that I then need to adapt.
So one of the tricky things about using a tool is working on zone-based graphics, where different kernels are employed on different scanlines - I was just playing around with hacking abb to superimpose a grid that helps me see the zones I am using for my current project(s) as well as a "test sprite" to get the size constraints.
-
Year end progress release for 2022-12-31... I made some detours ... but after spending the holidays experimenting with gameplay I could really use some feedback...
Updating the top post
On the face of it not that different:- still no score but there is a timer that ends the game after a set period of time
- still no sound except for a chime that starts to play when the game clock starts to run out
- just a few levels still
Changes
- a lot of experimentation, culminating in a couple of simple changes
- all players are effectively on autofire now - mashing the button has no benefit
- each player has a power reserve that replenishes over time
- behind the scenes the beams can have different physical and visual effects based on range and equipment type
- a few different ship types - two kinds of saucers, the maser tank, and the drone
- the two saucers play identically but have different beam patterns (purely visual difference at the moment)
- the drone (starts as the default for P2) is an AI opponent (same power as a saucer)
- the maser tank has an extremely short range beam - effectively acts as a shield
- a menu system lets you select your ship type and the play level
- general cleanup of as many framerate, beam and ball movement glitches as I could
Notes
- i have spent almost all my time playing versus the drone in the "void" level (no obstacles) as a way to figure out the core shooting mechanics - really really wanting to get better insights from actual play testing
- there are definitely situations where the ball can get jammed on objects and basically stall play (in "void" the sloped side of the goal is the one place this happens - the result of loopholes in how I handle collisions)
- there are still obvious visual glitches for the lower beam at extreme angles
- this is because to draw the lower beam I start at the top - and there are some situations where the desired starting position can't be handled by my kernel
- I have thoughts around having the beams actually do some reflecting/refracting but... for now I'm just letting them glitch away
- tank vs tank... the tanks have no secondary weapons ... and the ball won't move on its own...
- the tank is very OP versus the drone (which I did not expect)
- drone versus drone battles are a great way to find new glitches...-
1
-
-
The struggle to grok HMOVE is real.
FWIW I find this table calming to look at (HMOVE value vs what cycle you strobe the register => how much shifting happens)
http://www.qotile.net/minidig/code/hmove.txt-
1
-
-
11 hours ago, SpiceWare said:
If you'd like more info Part 6 of the CDFJ tutorial goes into detail on the 2600/7800 detection as well as the NTSC/PAL/SECAM detection. It contains lots of reference links.
Thanks I'm interested to start on that tutorial - hoping to carve out some time over the holidays to work on projects.
-
1
-
-
9 hours ago, alex_79 said:
It's possible (it's used sometimes to dump cartridges using the 2600 console itself), but it's not 100% reliable (pulling out the old cart doesn't cause problems usually, but the program crashes sometimes when you insert the new one), and likely not 100% safe too. Not something you want to use in a game.
Makes sense. Asking someone to damage/crash their system would not be cool - there would have to be a way to physically protect the console.
The presence of save files and internet could do a lot. Access to a clock would let you change the game on certain holidays, etc.
-
On 11/29/2022 at 12:51 AM, Andrew Davie said:
It's possible (with ARM) to auto-detect TV system (PAL/NTSC/SECAM). This could come under that category of breaking the 4th wall by using that knowledge, somehow.
That's interesting. I was thinking about things like what if the player has to somehow "use" the system internals to say, battle to intentionally fix a glitchy scan rate. In which case knowing the TV system might be useful. Or at least make different capabilities available depending on what machine you are on.
The other fourth wall idea in my head revolves around whether or not it's feasible to physically pull the cartridge out of the machine and put it back in reliably and without incident. Then you could have a situation where you ask the player to pull the cartridge - continue in a 128-byte RAM-only kernel - and then after completing the RAM-only section put the cartridge back in to continue. (Update: I can see from forum search this sort of thing has been discussed before)
-> 
->
-> 
-> 
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Slicks Racing
in batari Basic
Posted
@nooly - very cool project ... do you have your original Furnace music protoypes somewhere? I've been working off-and-on (mostly off) on getting furnace to support some sort of export and would love if someone wanted to try it out - or just have the music available for testing.