e5frog

Sounds likely it was an electrostatic discharge in one or the other direction, was it assembled and/or hooked up? Seems impossible not to touch ground if disassembling...

That will indeed keep 0-63 and the add 10 but... noEor: lr A, S xi $2b ; VERY IMPORTANT lr S, A You CAN NOT remove xi $2b from noEor you can make your additions after that lr S, A. Else you'll ruin the pseudorandom chain and get stuck in a shorter, possibly repetetive number series. Spark might have come from discharging capacitor or DC on the antenna output. Depending on were discharge went it might have gotten damaged.

The green field means something is written in the palette column, either going too far left (decrease in x) and looping over or too far right. Several rows, do the appear at the same time or in a special order? Try and skip parts that are plotted and see if you can figure out which part causes it. A few times I've had problems with pixels ending up in the wrong places, it was enough to clear ports used before plotting. Maybe out or outs have been used on the wrong port.

The "bz doEor" won't work as "lr A, S" doesn't set flags. As in my example code: http://channelf.se/veswiki/index.php?title=Snippet:Pseudorandom_numbers Where I use the combination of "clr" and "as 1" you should use "as S" to make "bz doEor" meaningful. Then you have "lr A, 7" where it should be "lr A, S". ... as well as everywhere else r7 is used - should say S. If you use r7 later, end with lr A, S lr 7, A. So: LFSR: ; Linear Feedback Shift Register ; save the return address ; r0 as temp reg ; 0o36 stored rnd no lisu 3 lisl 6 clr as S bz doEor lr 0, A ; Save original number in r0 sl 1 ; shift one step left lr S, A bz noEor ; Do XOR if b7 was 1, workaround for missing carry on "sl" lr A, 0 ni %10000000 bz noEor doEor: lr A, S xi $2b ; Do the XOR thing lr S, A noEor: lr A, S xi $2b ; VERY IMPORTANT lr S, A ; if needed: ; lr A, S ; lr 7, A ; Now you can handle your number, store in a temp register ; or fetch reg 0o36 in your code and then handle it locally. ; If wanting to check if valid number, repeat if it's not. ; (Can be done many many ways) ; ni %00111111 ; keeps only 0-63 ; ci 14 ; bp LFSR ; a number under 15 causes a loop for new number ; Possible numbers are [15,63] ; inc ; Now it's instead [16,64] in A ; lr 0, A ; Stores the edited pseudorandom number in ; register 0 for temporary (or other reg - not reg 0o36) ; keeping, if it can't be left in A ; You'll now keep getting a new pseusorandom number in reg 0o36 every time you call LFSR ; ...unless you write to it anywhere else in the code. pop ; return from the subroutine

I usually name the registers 'O'61, O61 or 061 (for octal 61). It's a bit annoying that they're named differently in MESSUI debugger. IIRC they're 0-63, if you want to set 062 to a value in the debugger a quick calculation is needed, it's R50 in debugger... Seems 0o62 would be a way of writing it, like 0x32 is for hex. That's why I usually make an initial table with octal and decimal numbers. ISAR can be loaded directly from A as well. LI $32 LR IS, A (and fetch the value with LR A, IS) If using that way of loading ISAR you can increase and decrease the ISAR number without thinking about the lack of carry on ISAR where octal 67 would change to 60 after an increase instead of 70. For the LFSR to work you need the previous number safely stored. Make sure you continue from the whole 8bit number and not your partial one. Seed one initial time by counting up a number while waiting for user interaction, when done place value in your LFSR memory position. If waiting for a keypress you can check that it's not pressed before allowing to stop counter - as it would otherwise be possible to get the same seed and then know the series of numbers that follows. When needing a random number you call the LFSR routine once. It's supposed to read from the reserved memory position and then write the new number there. Either you use it directly from A, store it in a temp position or read from reserved position. User actions in the game could generate a LFSR call to increase variation passing a position on screen, how many times a maneuver is done etc. I'd love to get involved but I need to get some other things done.

Check that you're not using the LFSR register for something else. Also wondered about 1k demo... I attempted IK but lost my geist when I realized the lookup table for animation frame and distance for each player would be a lot of work. IIRC there's one hit possibility, then it just resets to start position. If cheating, smaller players with less options perhaps. It's hard to revisit old stuff.

Open spots are filled. If you have a good excuse that you must pay for one right away (least waiting time), let me know and we'll work something out.

Just set the land to light green, using the possibility to set background color by line. Red looks terrible.

I have decided to accept pre-payment #12-14 if anyone's interested. Check first post in the thread, follow instructions - if you want to pay for your copy and get in line. I added an image of the real box original, the details will be a surprise.

Seems atari2600land hasn't released the new information on trimerous. In an amazingly impressive effort all the circuit boards have been soldered and are awaiting transport - as soon as box and label prints are done... Seems holiday is interfering with the printing, but sooon... Tetris boxes will be printed at the same time.

Built in reset routine and games are 2KiB hardwired at the start of the address space, so only $0800-$FFFF is available to the user. Free space to the user, with no tricks, is 62KiB which means 62*1024 = 63488, which is probably why someone came up with "Ki" or "K" as 62kB could be (correctly) interpreted as 62000 bytes . Trimerous actually has 42009 unused bytes, there's a gap because MAME/MESS has a fixed "Chess RAM" area, so to be able to test it in said emulator it needs to be skipped, no data is loaded there (for some odd reason) even if binary file has it. Almost all of the second half of trimerous is unused space. It's quite possible someone editing MAME/MESS could allow loading data into the "Chess RAM" area, that would help a lot, ideally it should allow configurable RAM in any area, like some other systems. If more than 62KiB (63488 Bytes) is needed, you can add more using a bank switch configuration - like the Multi-Cart has. It will however not be possible to test the entire thing in MESS/MAME though as it only emulates the normal address space and no special bank switching methods - unfortunately. Maybe if we present a fileformat like .chf that is based on .crt or similar with a header and where you can set type and blocks in the file - that would solve the problem as soon as it would be supported by emulator(s). Channel F programming community isn't as large as other formats though...

I'm working this summer, less than full time but still. So not leaving the comfort of my own home. If anyone needs some Multi-Cart gaming I can help out.

Looks like a very descent shipping price. Too bad there's no Japanese manuals or boxes (with stickers).

All orders made until today has been shipped. Still have some boards left (got another set as bandaid on the wounds as we say in Sweden - but in Swedish...) but I'm missing one type of IC and also SMD capacitors, they should arrive the coming week. I have a couple of other things I need to finish, so I might be less responsive for a while (weeks, months...? ). So Grab One Now Thanks everyone for your support.

Poor people sell, richer people buy - as they aren't spending money on other things, sitting home, polishing their collection maybe - there's money to buy stuff. Especially if one of those really unusual things pop up. Still got my job, not that I have money to spend at all since the wife finished studying (five years) and currently seeks employment in "specialized" healthcare and they all seem to be caught up in this Covid-19 business not let anyone have vacation etc. Hoping she gets the second job she interviewed for, we'll see. We work 24 hours a week at something like 95% of the salary instead of 40 hours, so that's pretty neat. In two months we'll see if we're back to normal again, seems orders are popping in a lot more than before at least in bursts. I have sold a few cartridges more than the mean number over the first quarter (sounds really business-y). Tetris is coming along, there's just 2 more features I must have, will check with the buyers about the rest, could probably spend many more months on it. So, for now it seems it's not bad to sell, if it's something unusual at least.

If I'm offered a $2200+ sure, otherwise it would go on eBay - even though comission and PayPal fees would be a drag. Agreed.

Not unless I really have to. We'll run out of high paying bidders eventually - when all of them has a copy.

Pretty decent price though, makes you wonder if you'd sell your own complete set for $1000 or more.

Put one out at $5000 with offers, see what is offered.

Not sure MESS handles the timer interrupts, I have thought about testing it out myself when timing stuff (seconds counter or whatever). You'd have to use DI/EI so it doesn't mess up the code. Do you know if the interrupt flag will be held until there's a EI, if it's disabled when the interrupt happens? If you get any results, please share. Nice table, it wasn't readable on my phone but it looks nice on the computer screen. I wondered about that as well the other day when checking the table after finding an error. Not sure MESS is the best place to try it, if they have used the same information. It should be possible to check it in the MESS/MAME code (somewhere). According to Lowell Turner those $xF result in NOP: http://www.nyx.net/~lturner/public_html/F8_ins.html EDIT: Registers 12, 13, 14 and 15 are the K and Q 16-bit registers so perhaps it would be odd to be able to call r15 directly like that.

Update: Box awaiting some text for the back side, got some help with that, then it's ready for print. Moved code to another editor for better overview and syntax checking, to date I have made 974 code compilations (where the code is compiled into binary) , some with small and some with larger changes. Many wasted since it only worked in emulation... :'( Also want to thank everyone for their patience.

62kB if you're not using bank switching...

Open it up and check, maybe there's ants or dead flies.

Hey there, still at it. Haven't found a solution to the mentioned technique used with the emulator. I'm considering a hardware solution but it feels like cheating and would prolong the development as it might require changes in cartridge hardware. Anyway, there are a couple of small details I want to sort out, it's those last ones that takes the most time. I may have to replace some routines to be able to get the different colored blocks I want instead of mono-colored blocks. There's three to work with, so why not use them all?

I have one board left if anyone's interested right away.