TomSon
-
Posts
46 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by TomSon
-
-
This is why the original game Threes is a lot more challenging... you can't use this technique much with it.
Well, I respectfully disagree - I've played Threes for a while again and do prefer 2048.
2048 feels more like a Rubiks Cube with some randomness thrown in. There are ways of beating it one can
find/puzzle out. Plus the power-of-2 values are just mesmerizing to a mathematical person and/or 8-bit programmer.
It does mean that there is an uneven skill progression in 2048 and you need a while to get to your current
level of skill - which I myself don't find annoying. With just a small change to the rules this can be improved upon,
which doesn't affect the more complex parts later that much, but I still feel it's unnecessary.
I did however add this second ruleset to a 'deluxe' version that will see the light of day eventually. Probably.
The rule change is simple: I allow more than two of the same tile values (pre move) to be combined for an exp(2)
higher value, so 2-2-2 = 8, or 4-4-4-4 = 32.
-
I discovered a new technique yesterday and straight away I got to the 1024 tile with 10300 as my top score. Haven't played it since. I think 2048 would have been doable but I made a mistake and then it was damage limitation. The technique? Slide all the big numbers to the top line and never slide down.
You are on the right track - there's a strategy that allows you to easily get to 1024 almost without thinking that I use myself.
Only afterwards does this strategy break down and I need to get more creative to reach 2048.
So far I haven't managed 4096 yet but I was close at one time, already had the 2048, 1024 and one 512
-
how time flies.. so here's the current state of things:
I have build and tested most of the VecFevers I plan to offer soon now but still don't have the time in the moment
to actually organize this. Those were build whenever I could spare some time during the summer, including 50
in a black case with LEDs:
-
6
-
-
Hi,
I’ve written a version of 2048 - a small puzzle game, originally by G. Cirulli - and kept it within
the 4K rom limit of the smallest, original GCE cartridges without having to compromise anywhere.
https://en.wikipedia.org/wiki/2048_(video_game)
It has an attract mode, sounds and keeps the current high score in the Vectrex high score string
just like the old games (so it is temporary and you see it by pressing reset).
Obviously you can play this on a multicart where you can add games but since it is so small you can also
quite easily build your own cartridge by converting an old one using a 2732 eprom and an original Vectrex 4K pcb.
I myself used a dead Berzerk cart. whose pcb/shell was lying around here for a few years.
In case you’ve never considered this: the Vectrex masked roms have /OE and A11 switched compared to a 2732 so
you have to reroute those lines. It’s quite easy since all you have to do is cut the two lines wiggling under the eprom
on the component side and reconnect.
So I’ve just cut at the red lines (didn’t have to for /OE since that trace was already missing), rubbed
off the paint from the two traces (green) and soldered the leg directly to it from the component side.
if you want to build your own - here's the label I've printed out to stick on mine:
-
10
-
-
We're having some odd results with the 2600/7800 detection routine for CDF.
what about checklng the stack pointer after reset - it's different for 2600/7800: FF on 7800, FD on 2600
-
1
-
-
hi,
just saw your replies (didn't get an automatic notification via atariage - can I enable this somehow ?!) and just wanted
to say that it's great to hear that you are changing Stella accordingly - I quite like the FE bank switching scheme myself.
It's elegant to implement in sw while at the same time simple to build in hw - even automatically initializes the bank during reset
since this triggers 1fe, too. If I ever write a <= 8K 2600 game it'll certainly be an FE one
Thomas
-
Hi, just wanted to write something here when I saw this, esp. since I am not only located in Germany but also in the
area where the people involved in the project are based. So I was lucky enough to speak frequently beforehand with
several people involved in this project. Plus I saw the finished cases on the 'DoReCo' party.
Just to be clear: I have no involvement myself and didn't get one for myself yet since I prefer the older, breadbox
cases simply since that's what I had as a kid.
I myself think the cases are quite nice, very nice in the original beige color case. Depending on the color choice
there are slight annealing marks a bit more visible in the plastic - which some people commented upon on local forums.
The ones I saw were at the expected places - mostly at the back of the case - and more noticeable with darker colors.
The SX color scheme showed this a bit less, the black one the most.
None of this is a deal-breaker for me and I keep thinking I should drive those 4 km to pick up a black one or maybe the
SX-colored one for myself.
-
2
-
-
I've finally obtained a NTSC 2600 for testing and tried my Tiara hw out on it: while playing
a whole bunch of different games I saw on this setup that the FE code was unstable: Decathlon
and Space Shuttle crashed, Robot Tank glitched (very rarely) but Thwocker worked just fine.
That surprised me a bit since much more complex things like AR or DPC(+) work.
However, FE was troublesome before, last time on the 7800, and I never fully understood why
certain timing changes helped so this didn't surprise me that much.
So, I've tested again on 7800 and two 2600 PAL where everything worked except Space Shuttle
on one PAL 2600 - sometimes it crashed which so far slipped through my testing.
At this point I decided to entirely rewrite the code from scratch, not based on the documentation
I saw before but using a simpler version that just checks rts/jsr access to the topmost stack
by the order of the incoming accesses to 1fe/1ff. Again no luck - Space Shuttle or Robot Tank now
work stable but Decathlon refuses to come up. I add/remove sanity checks (like whether the following
adr. is the one it's supposed to be) but this doesn't help either, however it does expose a strong hint
why Space Shuttle didn't work - a specific 1ff bus access pattern. Which gives me another idea,
because I had a very strong gut feeling anyways that all I'm doing is way too complex:
so, I ignore all documentation I might have read, e.g. that opcodes are detected on the bus (very
unlikely Imo, never tried that) or that the previous cycles adr. is used, or the next ones.
Because in hw the most easy thing to have implemented would have been to just wait for 1fe on
the bus and always latch the next cycles data bit for the bank address line.
And this is what I did and you know what: this minimal FE bus routine works flawlessly on all my
consoles, including the 7800. This increases my confidence in my theory quite a bit so I've
just got to ask: is there some proof that the FE bank switching method does use a more complex
mechanism than waiting for 1fe (or maybe more adresses $1xy with xy even, you'd just have to
ignore adr. lines). ?
Because from where I am standing everything else seems to break one game or the other here.
Thomas
p.s.
quite a long text but I thought maybe it's interesting to see how I attack something like this from
a bus emulation point of view
p.p.s.
I've just hooked up all my consoles and successfully tried this behavior with all the FE games I've got,
took a while...
-
7
-
-
What's the standard USB connector for, in addition to the micro USB that I presume is the usual way to connect it to your PC?
The VecFever also has a serial port - this standard usb is of a serial<->usb chip which fits neatly into
the case, too, although it does get really tight in there.
I've also added a (low-6809-cycle) way to access the serial connection via Vectrex cartridges.
-
Well, I've got excellent news and a slightly less good one.
First the less good one: it's vacation time and everyone is off to sunny and warm locations,
including myself, for a while.
The good one is that yesterday the cases were made - or rather the usb openings were
drilled with a cnc machine. And they turned out beautifully; so the dimensions of the pcb
and case, the precision of the cut - I'm a really picky guy but there's nothing I can
faul there - they are just perfect. The plastic was borderline useable for cnc-cutting, even
with coolant fluid over it all the time (and a knowledgable person fiddling with the
process parameters) quite a few cases were destroyed. Still, I decided to get this over
with and made probably all I'm likely to make for a while.
Friends also sent me a few (semi-)transparent ones to try out - they are really rare
in the moment but I wanted to try out the plastics, if some ever get available.
Surprisingly those seemed to work better so I'm a bit more open to actually make
another batch, if these ever get available. I've tried them out with the LED on the pcb
but apart from the one transparent one I've got the results weren't really useable in
Vectrex mode - you can hardly see the color of the LED under an orange or blue
case. The blue one is more useable for USB-mode, the orange one almost once you
know what 'blue' looks like there but my personal favorite is still just the black case.
The ones I've made for myself before have a LED on the outside corner of the case, so
it's still easy to see when in a Vectrex, I've put them in the photo with the colored ones
so you know what I'm talking about.
So, when I'm back from vacation (August or .maybe. early September, I'm a European so
plenty of vacation time..) I intend to make them available - either just the pcb if you
are a lucky owner of a transparent case already or want to use it as is. Or including
a case- in that case I'll still add a LED, in case you want to add one yourself eventually.
If you know you want to right away I probably can also drill the necessary 5mm hole for
you - I just don't want to add the LED myself because so far it took me quite some
time to get the LEDs in - adjusting the cabling and hot-glueing the LED in - and I'm
not certain whether the cable solder points on the Led side would survive a really
rough postal handling..
Thomas
p.s.
(the black ones in the photo below are just a few of the ones I've got now..)
-
5
-
-
Yep, no shifting required. All 128 pixels are drawn using only the players in triplicate with RESPx tricks.
I'll try a similar approach to this modified kernel then, too, maybe it works on my 'bad' TIA..
-
Timing can change on some units, with warm-up. Check out this video, originally from this post.
Great video to explain what I'm seeing: that's a very similar in-between behavior I am
seeing on that TIA, only with 1-pixel offsets at the very start of the line.
So only the first chars wiggle a bit until they descend into the stable, warm delay.
-
cd-w figured out an arrangement where we no longer need to shift characters, and thus can output 128 discrete pixels per scanline. See replies 133 onward.
Hmm, I thought the shift is still required but the gaps are handled via balls - might have misunderstood that.
That's why I called this a '32 char' kernel, not a 128 pixel kernel but I did use the term 'bitmap' before w/o mentioning
the gaps (since they are no problems here); so from now on I better call this just a char kernel.
If this indeed is different for the sprite handling I might try it, too, if only to test it with a specific TIA I've got (and
replaced) that's on the way to IC heaven: when it heats up, it starts delaying the very first sprite horz. by one pixel.
This takes a few seconds when heating up - in-between output is erratic from scanline to scanline.
Thing is - I cannot decide whether the TIA is actually failing or the kernel only works on a subset of chips reliably.
It's not a real problem for the Tiara since it can switch menu displays on the fly (already ntsc/secam/pal
variants of four menu displays are in there) but I'd like to understand this better. Has anyone seen something similar ?
-
Here's a weird question-- are the text characters nibble-encoded? (I'm judging, based on the letter-pairs, in your list.)
I had devised such a solution for the text in Cat Quest, and had gotten it down to 133 bytes. (4KB game)
Yes, the chars are in nibbles - you can also see from that source snippet that some are shifted, just like the
'normal' 32 char kernel setup. In theory a 650x could construct a bitmap function easily, too, if you had enough RAM
(32K via e.g. 3E would be sufficient) but it's much faster just letting the Tiara processor
auto-generate the code when the 2600 isn't drawing anything into the menu F4 cartridge.
-
It's not as ideal as the current way, but "a way would have been found" was what I was replying to.
Just reading this I remembered a conversation with someone about attacking the encryption of early European tv cards.
Similar to the NES lockout chip. Or the xbox 360: you take over by hammering the bus or certain lines.
For the 7800 it would be almost gentle: when the cart. is mapped in for the checks it is in 7800 mode and starts something that'll
decide what is plugged in. So if and only if your cartridge is accessed for the first time, pull the data bus to zero for a defined time:
the CPU ends up using the external cartridges BRK vector.
(Not what I've implemented in the Tiara since a uProc can do a more intelligent attack)
-
1
-
-
Hah, another physicist
Sorry for derailing the discussion, but I have to ask: what domain of physics did you work on? I used to do research in theoretical particle physics solid state physics: semiconductors
That reminds me to visit CERN - I wanted to visit for ages..-
1
-
-
Sigh, I won't get into the details of how to calculate error margins - and how many data points you need for a higher precision - because
I do realize that is both tedious and probably my reaction just a result of my studies and background.
Nonetheless .2% isn't really low, remember that the precision of both the uProc and the 30+ year old clock generator have to be taken
into account. Nonetheless, 'on average' this will work better than no detection whatsoever so I agree, this is a detection scheme.
Just not a 100% reliable one, until proven.
-
As Thomas says, not true anymore. We can even detect if it's a SECAM 2600.
Again, what are the error margins ?
Come to think of it - what are the error margins on a 30-year old frequency part you test against ?
Sorry, I am also a physicist by education so I usually wonder about these.
The clock rates I see are all within a 1% error margin (PAL/SECAM/NTSC). To put this into perspective:
the internal clock accuracy of modern uProcs -the STM32F4 again- is 1%.
-
Not 100% true for the 2600 anymore...
You know, when I was writing that I already had at the back of my mind the expectation/hope that someone might mention something
Are you certain that this reliably works on a Harmony - what are the frequency precision +/- percentages there ?
I am specifically asking because I had to handle these (and know that they can change from part to part) so you need a known error margin
that is small enough.
Nonetheless I'll investigate this since I should be able to get the same measurements up there, too. Plenty of unused timers to play around
with.. Obviously no need to check for a 7800 via this, too, I already know when one is present..
-
1
-
-
!!! Massive thanks to RevEng for helping me with a Tiara 7800 menu !!!
I've just finished the 7800 menu and tested it for a while so here are a few (rather bad, sorry)
pictures as proof.
so - a 2600 Tiara can run in 7800 mode and start 2600 games, that is implemented and working.
How is this done ? I detect the 7800 and behave differently in time to weave my way through
the 7800 BIOS checks to inject something into the 7800. This is tested on a PAL 7800 but should
work equally on the NTSC one and pretty much all patched BIOS versions, too, since all of them
need to check for a 2600 cart. - which I base my detection and handling on.
This is excellent since it allows me to already test quite a bit of a 7800-Tiara, esp. Maria access,
on near-final hardware. And having a 7800 menu is obviously very nice for a 2600 multicart.
Plus since one can actually detect NTSC/PAL on a 7800 (and not on a 2600) automatically and come
up in the correct menu, too, which is also nice.
So my next retro hw project is most likely settled - a proper 7800-Tiara.
-
5
-
-
TomSon, on what addresses is the tiara triggering? 6502.ts is listening on 0x00 - 0x3F, and including reads will cause most Tigervision games to crash and burn (hang and display garbage right on startup, no exhaustive testing required). As side note, reading from an invalid address will not put zero on the bus. The way the VCS is wired, if nothing drives the bus, a read will usually return the last valid value. This is pivotal in correctly emulating many cartridges
EDIT: I just checked in the debugger: for Miner 2049er, one of the problematic accesses happens at 0x306C during a "STA $07,X" --- the third cycle is a read from $07 that puts $07 on the data bus.
'invalid adr.': when the 650x accesses the cart. the adr. is valid and the cart supplies the data, nothing else better put their eager
data pins on the bus.. and when I <assume> a CPU write cycle the data is either really put on the bus by the CPU or it's a
CPU-read - then noone drives it.
'3F': checked the code today since I was hardening it for 7800 anyways and tested this a bit - I only trigger at 3F in the moment
and see a few uncommented lines w/ comments that e.g. Miner indeed has problems when I enlarge to the 0-3F range.
Tried this again and sure enough, Miner II glitches.
-
Also the Melody option of Harmony allows people to design much advanced games, so that should also be an option for Tiara.
Cool!
I would love to see this in real life action.I assume the 'Melody' is a stripped down version, or the Harmony has some extensions on top ?
The probably smallest, similar project I've brought up so far is the C64 SuperKernal, basically a Tiara pcb cut to the
barest bone one could think of. This shows how small a game-Tiara could be - for a single game cart. of at least 768KB
uncompressed plus permanent data storage for scores/options or more compressed (in the VecFever
firmware all cartridges are compressed, for example).
Probably more could be squeezed in with a bit of work but the above spec. would exist after just a day or two.
You may would want the capability to add more than one cartridge and a dedicated menu since this is probably
quite a bit for one game alone..
-
4
-
-
hmm, Tiaras 3F implementation is agnostic to reads/writes.
If the cpu uses a read to trigger the Tiara would read a 'zero' value on the bus since the cpu isn't supplying data.
Just played a round of Miner 2049er again - no problems with this behavior that I can see.
Same with FA - the adr. on the bus is the trigger for switching and nothing is put onto the bus for FA bank switch regs (in case it's a write).
-
1
-
-
Tiara looks more powerful than Harmony or Encore. Have you estimated the cost if you would produce it?
Yes.. and it would be quite easy to do - it is more a question of whether I want to do this; First I'd have to build >=100 to get the price down.
And if I would not only provide a pcb would need to get Atari carts. from somewhere and adapt them.. and I'm having enough hobby-time
filled up with the VecFever production already. At least I would know better how to avoid costly problems (in time/money) - at least the ones
I've hit with the VecFever
ThomasJ: I could loan one of my current backup Tiaras to you for a while if you want to take a look - seeing that you live next door.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
VecFever
in Vectrex
Posted
I've given the DS2431 code to Malban for his Release/Quappe - so those tested DS2431 source files are in the Release source code.
The code can also be developed/tested via VIDE already. If that's not enough PM me - I myself use a custom VecFever cart. where
I can download and test new 1-wire code+hw immediately. Most of my games are 64k but at the same time use a 1-wire setup
for storing/loading options/scores - that's possible if the data accesses to the 2nd bank are rare and esp. a lot faster than
access time of the 1-wire chip.
VecFever detection is simple - there's a communication structure that flags to the VecFever what type of features
one wants - e.g. 0-7fff read/writeable, or load/store capability, or LEDs etc. - and the VecFever, if present, sets an 'I exist' flag
in there. I could store inside the ARM chip itself also - not on the drive - and did just that on related projects of mine
but for the VecFever it doesn't make sense.
However, I have implemented an abstraction layer using overprovisioning and delayed erasure of blocks so storing on the drive
is near-instant and safe long-term since I only erase a block when I absolutely have to and shuffle those blocks around.
It's a .lot. faster than storing on a DS2431, for example.