All Activity

"Help the astronauts who populated the red planet to move to new space colonies, before the enemy ends their mission!"

"Travel through the countless dimensions of the cosmos! STELLAR - A space adventure for the ATARI 2600!"

Fantastic work, James! I look forward to checking out any future builds! Regarding a physical release, why not swap out the sprites for Pac-Man and the ghosts with your cats? You could call the game, Treat Time.

I haven't checked it yet, but there should be a difference if the sprite is out of the right or bottom boundary compared to upper or left (if normal drawing is used).

It's a common mistake. The original device was just called SIO2PC and provided a standard serial port DE-9 interface for connecting to your PC. So, the device you're referring to is just that with a USB interface instead of a standard serial interface (well, USB is serial too... but...). Here's the device that's properly referred to as an SIO2USB.

SUZY does burst read, but no parallel or out-of-order processing. And no pre-fetching of the next SCB.

… and a PAL release in sight? 😃

Thanks for the spot. You are correct, I am referring to the SIO2PC-USB device. I noted from a little googling there seemed to be more than one device people were calling SIO2USB, at least one of which was a similar cable to PC as opposed to the flash solutions you mention, which I saw referred to as SIO2SD. I certainly don't want to add to any confusion, so have updated description of video and edited contents to reflect my error.

Yes, SUZY skips it, so there is no effect on the drawing time, but I think that the loading time of the sprite data into SUZY is different if the sprites are chained or not. If I remember well, reading the Lynx patents it seems that SUZY has some data buffer in it and at low level it should prefetch some data for the next sprite while it parses the current one. Is this correct?

A sprite off-screen is not drawn at all. SUZY skips it. So the same sprite takes different number of cycles whether it is fully, partly or not inside the 160x102 pixels of the render buffer.

Hi guys, Back with NeoGeoNow on more on what he has to say. Will there be a season 3 for King of Fighters XV? Anthony...

Thanks for the clarification. So basically I should consider Capcom+ HDMI vs better battery life. Saw a deal for the XPR for 110 euro so I might just go for that

Did Brad at BEST have any? DavidMil2

...and Video Pinball.

Hi guys, Nalua Studio @NaluaStudio What do you think our heroes (Candy, Golem & Loony) are up to in this wonderful sneak peek of one of the newest cutscenes in Vengeance Hunters? 1. Beat a boss and moving on 2. A jog in the wastelands 3. Chasing an ice-cream truck Kercy 10:58 PM · Apr 17, 2024 Anthony...

Hi guys, Snkmvsx@MVSXHOMEARCADE Hong Kong Electronics Fair(Spring Edition) SNK NEOGEO games hold a special appeal for them! Fair #HONGKONGFAIR 4:30 AM · Apr 17, 2024 Anthony..

You already know how to do poke and peek in Pascal, with the dual data type. Poke the VDP read address port to the VDP, then peek the VDP read data port from the VDP. If you want to write to VDP RAM or to VDP registers, you need to set the second or first bit in the address. Remember that UCSD Pascal can do bitwise logic functions by using the odd and ord functions. So you can do VDP_address := ord(odd(16384) or odd(your_address)); where both VDP_address and your_address are integers. That will set the VDP address for a write (which you don't need for GCHAR, of course). Also note that you'll need to create a swapbyte function, but there you can do a dual data type with an integer and a packed array[0..1] of byte, where byte is 0..255, to handle that. A word of caution! In the example above the constant 4000H is represented by the 2's complement decimal number 16384. If you want to get the equivalent of 8000H into a decimal number, you can not use the constant -32768! Since that number can't be negated without an overflow (there is no +32768 in the range of 2's complement 16-bit numbers) it will be handled like a long integer constant, occupying two words, not one. But you can use 32767+1, as UCSD Pascal does no overflow detection on integer arithmetic. As long as you don't divide by zero, that is. Note that for this direct VDP access to work you need to manually set the code type to M_9900, since if it's M_PSEUDO then the code usually will be loaded in VDP RAM. If you then change the read address the PME will get lost about where the code is. The PME will only set the VDP read address when performing a jump. If you link in an assembly procedure into your Pascal program the linker will set the code type automatically, since assembly can't run from VDP RAM. But the compiler can't know which memory you'll access in a Pascal program, so there it's not automatic.

Ah! Great to know Dopey. I really would like to see the end results towards it. You're welcome brother man. Glad to have you aboard and always a pleasure to read your postings that you share with us here on the Neo-Geo thread and throughout AtariAge. Can't wait to see your need title you purchase soon for your unit for sure. Thinking of adding a Neo Geo Pocket Color to your collection Dopy? Such an underrated handheld unit with fantastic games to play. Maybe @shane857 and our friend @Reloaded85x would like to add that handheld to the collection as well. Anthony...

So many great options. I think I'm going to take my time and think about them and what my goal is regarding the TI. Since I can already play most of the cartridges on my https://batocera.org/ system, as I said this would only be for running disk or cassette based games. If Classic99 can run those then the actual TI unit with PBox becomes nothing more than a nostalgia machine and without the room to have it on permanent display, I'll need to think about spending a few hundred bucks on modding the TI. I'm going to open up and examine the PBox and test it. Let me see how well it works and if I can find a place for the box on the floor, that cable solution might be best depending on the condition of the PBox. You all have been so great with all this excellent info. I so hope to meet some of you at the Chicago TI Faire if you are able to make the trek up (or down LOL) here in October!

+5.23V but nevermind, I've tested 2 of my boards with it (my rock-solid, didn't need an R4 at all one, along with the 16MB stacked chip one - both running at 266MHz) and it passed the SAMS test on both up to 1MB where I switched off the machine. I also ran some other SAMS tests and they all passed too. This isn't unexpected though, there's a few things about this machine which makes me think it's only ever had limited use - so is practically in brand new condition... These are the things I know about it: 1. It came from Texas and doesn't have the V2.2 GROMs. 2. The felt strip in the GROM port is totally clean, I even left it in, which BITD I never would have done. 3. There was a hand-written 'extra' page in the manuals, clearly written by a child (pencil & large letters) with notes about TI BASIC. 4. The power board switch was broken, which I've replaced, the small metal conductors were not inside the machine, I checked before 1st power-up. 5. I've measured the master clock speed and I get repeating values of 3.030 - 3.030 - 2.941 MHz - so it's running at almost exactly 3.0MHz average. I'd say the early 80's kid had broken the switch early on (bad design in the beige model, using the switch itself as a stopper) and it's been in storage ever since.

Version Sub-version Analog audio outputs Audio output method Audio output coupling caps Digital audio output (spdif) Keyboard method Paddle method Audio input Spare IO Board Changes Issues 1 Compo 4 Sigma delta + rc (3.3v) FALSE FALSE io expander lm339 comparator 1 2 side, 2 layer, regulator sticks out, pin header on right Very quiet, paddles incorrect, keyboard issue with tkii 1 Final 4 Sigma delta + rc (3.3v) FALSE FALSE io expander lm339 comparator 1 2 side, 2 layer, regulator sticks out, pin header on right Make louder (rc values), fixed paddles(remove parts) Still fairly quiet, not enough io, keyboard issue with tkii 2 4 Sigma delta + rc (5v via buffer) FALSE FALSE io expander lm339 comparator 3 2 side, 2 layer, close to pokey size, pin header on right Added io, buffer chip for output, smaller Could still use more spare io, keyboard issue with tkii 2 b 4 Sigma delta + rc (5v via buffer) TRUE FALSE io expander lm339 comparator 3 2 side, 2 layer, close to pokey size, pin header on right Added ac coupling caps Could still use more spare io, keyboard issue with tkii 3 4 Sigma delta + rc + op-amp scaled TRUE TRUE io expander lm339 comparator Analog mixing via op-amp 11 2 side, 4 layer, close to pokey size, pin header on right. Parts on both sides! Op-amp audio output, analog mixing, lots of io Expensive to produce, keyboard issue with tkii 4 3 Sigma delta + rc + op-amp scaled TRUE TRUE FPGA direct FPGA LVDS build-in comparators Digital mixing 10 2 side, 2 layer, close to pokey size, inland headers Remove io expander, small smaller and cheaper pokeymax_features matrix.xlsx

Thanks, I always be trapped by this sort of things.

While it wouldn't be easy to make an acrylic 1090XL case, it wouldn't be that hard either. You can buy acrylic rod that is concave/convex. You would just have to 'glue' the top piece and side pieces to them. All told, it would only require six large pieces for the top, sides, front, back, and bottom, and the two 'rolled' pieces for the top edges. You'd also need some smaller pieces for support and alignment. Plus a great deal of measuring and patience. While I do have an acrylic case for my 1088XEL, I don't think the 1090XL would look right without the brown front/top/sides and the big 'ATARI' written on the front. DavidMil2

Well the pokeymax project, as entered to abbuc, was intended to provide a low cost simple pokey replacement that supports all features in close to the original chip footprint. Nowadays there is more spare IO exposed from the FPGA allowing various modules to be enabled at core synthesis time, mostly mapped in a standard software discoverable way. The modules available are: i) Pokey! ii) SID including decent filter for 6581 and 8580 as used in the C64. iii) YM2149 (PSG) as used in the ST iv) Covox v) Covox extension that can play samples from internal fpga ram, compressed using adpcm. Like Paula on the Amiga but uses its own memory due to system memory constraints. vi) PS2 keyboard support with fixed Atari key positional mapping (like the EclaireXL) vii) SPDIF output viii) Analog output ix) Flash support (needed for data for some of the above, otherwise used to store settings) There all take space, so you can decide what to enable based on the size of the FPGA you fit. The 'full' setup I used on the largest 10M16 (recommended) ones is quad pokey, dual sid, dual psg, covox with sample, spdif, analog, ps2 As to what v1-v4 bring, I'll post a small table shortly.

Depending on how much room there is inside the touch pad, you could try and find membrane keypad the rich size and use that instead sitting it between the PCB and original membrane. Alternatively it may be possible to create a new PCB with surface mounted membrane switches that would replace the original PCB.