Wrote C-65 Game "XEVIOUS" (Atari-Namco) team. Ask (me) anything non-secret C64 - Page 1
Forum section: electronics / general

author: RJSV
author_rank: Super Contributor
timestamp: August 11, 2020, 05:08:37 am
content: You can ask, coding bit maps, etc. 6502 general questions, won't hurt game, that was 1986Good advice on LOOPs, etc.Medium level guidance, but try me. Didn't learn much on audio, however.

author: MK14
author_rank: Super Contributor
timestamp: August 11, 2020, 06:12:42 am
content: Like this (related) online playable version ?https://www.retrogames.cz/play_049-NES.php?language=ENKeys.Z seems to fire and work if permanently held.X seems to work, without needing to release Z, and drops bombs onto the field.The array keys move up, down, left and right.The following video, seems to be an original from around 1982. It rather nicely explains how to play it, and demonstrates it well. If you like retro/vintage stuff, it is probably worth watching.

author: RJSV
author_rank: Super Contributor
timestamp: August 11, 2020, 06:37:10 am
content: Uh, thanks; we meet again, well I'm not familiar with that specific version:We were approached to form a re-write team, creating an action-matching game stored on C-64 floppy. The big CORP. Namco took care of added copy-prevention and sales, etc.We had a sit-down style Arcade quality system, to beat on, while an artist went to work, making screens and sprites (simplified moving bit- mapped objects.)But very close look, to your picture, up top there.We used virtually all memory, C-64 has 64k RAM, plus alternate mapped ROM in 16k (?) chunks.For map changes, you could flip which one was current and I (think) still get at things in other 16k blocks, without switching constantly.Keystrokes control, that was 'other person's job, but he would pass parameters, to graphic portions of code for display and animation. The bullets moving for example, were directly animated, using XOR, for blinking, madly, against a scrolling screen (a speed issue).My neighbor was Arcade machine service biz, so that was a happy coincidence, the martial arts and car race stuff so cherished today... Like 'Lost in Space' episodes.

author: RJSV
author_rank: Super Contributor
timestamp: August 12, 2020, 08:23:57 pm
content: Someone Taught Me a method:. a CODE TOWER.With C-64 processor speeds, here is a helpfull Graphics handling:You have to, example, put every pixel to '11', a Commodore specific, but it is simply 4 pixels packed into the 8, each Byte.The 'tower' is just a bland stack of repetitive instr, often looking like this example:Lda #08 hLoop_Block1STA. 2100, YSTA. 2260, YSTA. 2420, YSTA. 2580, Y.INY. That's equiv to index++Branch back, etc. to Loop_BlockThe graphics is not all that convoluted, on the C-64,but requires considerable 'bulk' of details.When doing 8 kB screen copy, that CODE-STACK above has each 'cell' something like this:LDA. 4100,YSTA. 8100, YINY

author: james_s
author_rank: Super Contributor
timestamp: August 12, 2020, 10:15:41 pm
content: Xevious could have been a decent game but it had such horrible "music", seems like it was 4 or 5 notes over and over and over. It could drill a hole in your head.

author: MK14
author_rank: Super Contributor
timestamp: August 12, 2020, 10:54:05 pm
content: Quote from: james_s on August 12, 2020, 10:15:41 pmI'm NOT trying to say you are wrong, as such. But, the OP did say:Quote from: RJHayward on August 11, 2020, 05:08:37 amSo, presumably they were not involved with that part of the software (conversion).In the playable version of the game I linked to earlier. (Which the OP, said is NOT the specific version, they were involved with). I did play with it, for a limited while. The music (if I dare say that), was ________/ Where ____, means I have run out of words to describe, how bad and repetitive it sounds.I bet, a 3 year old, playing on a $2.99 kids toy electronic organ, at the exact time these games were written/created. Could play something, considerably better.Unfortunately, I'm NOT joking here. (Or not much, anyway).

author: RJSV
author_rank: Super Contributor
timestamp: August 12, 2020, 11:14:30 pm
content: ALL Honesty, audio prog, was (is) miles beyond my (moral compass). Many times, we lie, innocently, but I would not try... The dude actually taught me some coding trivia, but usefully !The little bird that sings, changing the subject, seems to pipe actual 'audio' thumps, to the little motors, for wings. So the recent toys teach a lot, of new approaches.

author: Alex Eisenhut
author_rank: Super Contributor
timestamp: August 13, 2020, 03:57:35 am
content: As a kid that was my favorite game in the arcade! It was hypnotic, I don't know why.

author: RJSV
author_rank: Super Contributor
timestamp: August 13, 2020, 08:31:19 pm
content: Thank you Alex, I guess my fave is 'RYGAR'Briefly, I checked and est using a so-called "Code Tower" can be 2 X faster, the C-64 often has 25 at once, plus better to use Y index downward, faster checking.You can 'race' the actual video beam, starting it just behind it. Then, a 50 hz or 60 hz scan will eventually catch up, but has retrace delay too.This way, avoiding flicker inducing.C-64 has the Beam-Retrace, bit flag.(Hope that was correct ?)

author: RJSV
author_rank: Super Contributor
timestamp: August 23, 2020, 03:50:22 am
content: I also wanted to layout some (typical) C-64 screen graphics handling, mostly the bit mapped and scrolling screen, of XEVIOUS.Well, we actually borrowed some pretty common stuff, TILES and STAMPs, where the stamps are really explained in the hardware: however a 'TILE' being a pure software structure (again common in game machines.)So, a TILE is a quick list, has a 2 by 2 square, listing the contents being stamps. The artist chooses the 4 desired stamps, often having a set up to 256 stamps.A sub-structure to the tile system, each stamp is an actual little bit-map, 4pixels wide by 8 (lines) high.So for the copy of one stamp, you would copy 8 bytes sequentially, each byte has 2 bit pixels packed 4 to a (byte). Usually, that code is with a speed concern, so no individual pixel is of concern. You can then imagine, a TILE structure would be a list, of so-called pointers or 'stamp' numbers. That actual hardware map is Commodore specific, but the TILE data can be anywhere convinient.There was also color and size varieties as TILE and 'stamp' set ups were a hybrid, pure software plus the hardware derived 'stamps'.For movement, this code was for the background, there was movement, but only vertical 'scrolling' for 8 lines worth of (whole) screen offset... Then, it was necessary to sort-of 'jump' by 8, that accomplished as a new screen, another whole screen mapped.That alternate screen would then be, as before, moved vertically, counting out 8 lines worth.Meanwhile, another new bit map screen would be built up, tile by tile,... stamp by stamp.It's a mess, on the C-64 and used 70 percent of CPU clocks, just for XEVIOUS scrolling screen.

author: MK14
author_rank: Super Contributor
timestamp: August 23, 2020, 04:15:15 am
content: It must have been very difficult, in those days. With so little capabilities (compared to modern times), on the 6502 (relatively slow, by today's standards), packing all that functionality into only 64K of Ram (not all of which was easily accessible, as you previously mentioned).I suppose, those were the days of the hero software creators.I presume, it must have taken a lot of skill and patience, to do that then.Even the powerful desktop PCs (or laptops), we nowadays would use, to perform/develop such software, did not necessarily exist (not invented and/or available, if long enough ago), or was too expensive at the time, for everyone to have one.Even if you did have such a PC, it would have been an ancient specification one. Not necessarily having a hard disk, high resolution screen, or even a colour screen (many early computers, had only monochrome).No windows, no mouse (I guess), no access to the internet, in those days. No forums for asking questions.No mobile/cell phones, for asking colleagues for help. Not even that much in the way of software packages, to help the design process along, even Microsoft paint, wasn't around then.I've probably missed other modern technological wonders, we take for granted, that you didn't have access to then.

author: RJSV
author_rank: Super Contributor
timestamp: August 23, 2020, 09:03:45 am
content: "Stone Knives and Bear Skins...". Doc McCoy"...you follow the CODE: The CODE a the DORK..."...- gamer artist GregYes, heady times w ZEVIOUS, heady times. We, in the moment had sacrificed, and each thinking: how much we wanted this (tormented task)!So, to continue, for coding a scrolling screen, pls don't imagine the 'TILE' graphics as being set down on a whole screen: rather it's a series of block moves.Then, a row of new TILEs are put across the top.Now, once written the hires graphics are a simple bunch of stamps, copied onto the hardware bitmap (block of 8k screen memory). Between the preparatory block move ( down) and the new TILE lay, each new screen is complete.Next, a timed switch of maps takes place, substituting each new screen, while old mapped (8k) screen will be completely re-built, for next display, eight steps of scroll further down.Across, there were ten med size TILEs (20 stamps), for a 'whopping' 160 pixel screen width."NEVER write code to move large blocks of data!"-- Rodney Zak's, author of "The Z-80 Prog Manual"

author: RJSV
author_rank: Super Contributor
timestamp: August 23, 2020, 09:16:22 pm
content: Oops, meant to say "there are 20 TILEs across the screen top", not ten. It helps also, to imagine each 'stamp' as in a regular text character sized box.For those interested in game development / production tools (MK14 et Al) I used the HESMON debug monitor, a game cartridge with ROM that could take over, for examine 6502 (6510) registers in usual bug fighting.But that was the limit of (my) expertise. Bought my system, thick Commodore users manual, dot mat printer, (and HESMON cart) at TOYS 'R US... Yeah, I know, pretty saavy, there.Ted (also Larry) was the real hero... Supplied support with MS-DOS system, for the glue that brought all together, graphics, code, disk loader; All that came Via MSDOS... saved all our butts.The artist had a MAC, the only real system in that office! It was shared, president, marketing, shipping, everyone used that one 1985 Apple Mac.Things didn't go well, always, and I don't say that to complain: My choice here is to avoid the colorfully history, for helping those wanting to write CODE, on a C-64 orig or heritage copy. Hayward city is 30 minute drive, to former ATARI buildings, by the way. I could write, colorfully stories, "lookit those older bullet holes, in my apartment wall, there". But for that, remember that movie: 'Pulp Fiction'. (Hayward has similar past).Looking at first diagram, shows 4 of the bit-map 'stamps' making up one TILE. A register-indirect creates each for color. Your bit pair will specify the register, that's in one of 3 places, each a byte, in coordinated blocks, elsewhere in RAM. So a 11 for example, tells hardware (video VID IC) to use the color RAM, to get the ultimate color.For two other colors, the indirect points to proper nibble (register) this time in the 1k 'screen RAM'; that's where text typing is, in low res modes.So you've got maps all over the place, different resolutions, result is you can call 'FourColor', chosen from 16 possible color options. One subtle aspect, using the common TILE and STAMP system, the stamp provides shape, the tile assigns colors, so a full screen can include ALL shades, the restriction comes at each little local area, with four (shades) available.Clear as mud, plus my babbling. Don't let that quit you:. Get the damn BOOK!Now, the first diagram was limited, to show a single color (actually that's a sprite, SPACE-SHIP), and second diagram shows full TILE: the green pixels are done register-indirect, to using high nibble, corresponding directly to that mapped stamp. Literally,the full 8k is mapped down into corresponding 1k, which is calculated using quick bit shifting, but also zig-zagging along with the hi-res zig-zagging map..WHEW, this is hard to explain, consider!Clearasmud, clearasmud.Now, take a glance at the hex address, see the left side, of a TILE at 4100 h. Notice the lower stamp; it has location 41A0 h. That shows, right there, the 160 byte offset, A0 h being 160 decimal. To follow that, you walk down, 8 bytes(lines) then zigzag up to next stamp. Doing that across gives 160 bytes, 40 stamps by 8 bytes each. OR, 20 TILES across, remember each is a 2 by 2 organization.For those truly into doing some, please look around for that (thick) Commodore book / manual... It was 6 by 8 inches, with heavy binding loops.That maybe clear but not at first!

author: RJSV
author_rank: Super Contributor
timestamp: August 24, 2020, 04:24:42 am
content: Errors last time, realized that the offset is +320, for the C-64 HiRes, row to row (of 8line stamps). So corrected TILE diagram shows, 4100 h + 140 h that's your 320 bytes. I show, also location 4247 h and encircled that (slice of 4 pixels).Right now, going to show some code example, the routine for 'new' tiles operates using partial tiles, an even or odd scheme for scrolling (hardware really only thinks it's a set of stamps.)Next_Stamp. Gets A= the stamp no.* and converts to point to stamp bit map (at 2k -4k)LDA (46),X. X has index into tileINX. Next stampSTA 80h. Low ptrLDA #01h. This will be shifted three times, to 0800STA 81h*ASL 80ROL 81ASL 80ROL 81ASL 80ROL 81* this code just mult by 8, plus 16 bit baseRET**. Ok here is the stamp copy part*JSR Next_Stamp get pointer to stamp in storageLDY #7. 8 slicesLoop_stamp1:LDA (80),YSTA 4100,Y. to screenDEY. nextBR NZ Loop_stamp1LDA (80),YSTA 4100,Y. last slice*JSR. Next_StampLDY #7Loop_Stamp2:LDA (80),YSTA 4108,Y. this is the 320 byte displacementDEYBR NZ Loop_Stamp2LDA (80),YSTA 4108,Y. last slice**OK, now please if you want to appreciate the power, of 6502 instructions, the 16 bit pointer used for retrieving a bunch of bit map slices, this above code is a nice start. Notice the bit ROTATES and SHIFTS, effortless, nearly. Well, it ALMOST makes up for other headaches right there.Study that multiply, and adding of 16 bit base...Where's that, you say? How's that?(Didn't see a multiply)....RJHayward Aug. 2020

author: RJSV
author_rank: Super Contributor
timestamp: August 24, 2020, 04:53:24 pm
content: "He said the MEMORY is all Zig--Zaggy...."Oh, the horror!"...PAGE ZERO !!... Sounds like a celebrity, name..." "... besides: the functions don't even USE the accum."I've heard some of that. So some speculation, if (ever) going to be some kind of re-issue. But I'd like, if that happens, like to see some C-64 vintage magazines and, particularly interested in an 'official' SCHEMATIC.The C-64 'VID' chip, well, has a shadow RAM chip: I believe it is 4 bit wide, by 1k. That's a DMA optional set up, where the VID reads (color nibble of interest) directly. Programmers simply write to the separate memory IC, even Basic, and that is mapped, way way up top, maybe up near 58k 'ish.Anyway, that right there could be basis of some (phoney) intrique: 'Secret chip buried under C-64 volume control...'.But actually, it's an everything scatter-map. You have the 64kb, under there, plus the '1k color ram', on top.The processor has that 64k limit, and registers / code is all focus, on the 64k range (16bit address)."...this guy doesn't cough up any corrections, for daysif at all..."Oh well, -- corrections and bug fixes are where you make your money )lol)So, for the last coding with bit shifts, here is detail:Say stamp number 7.You want 7 x 8 plus a base of 0800 h.A quick glance, you realize you can start with01 07 h and that 1 can be shifted, along with the stamp number. Otherwise, your code will simply do a pair of 8 bit adds, (ADC instr).Honestly, big part of code writing is getting your locations of use (in page zero).So, 01 07h looks like 0000 0001 0000 0111 bNow with three shifts, effectively each is a 16 bit,instr:. ASLand. ROL (each on pg 0 reg)So, in total you've got a 16 bit shift, with the right details, such as the first instr shifts in a 0, while second, high byte, gets the CARRY proper.Any C-64 SCHEMATICs out there

author: MK14
author_rank: Super Contributor
timestamp: August 24, 2020, 05:20:59 pm
content: Quote from: RJHayward on August 24, 2020, 04:53:24 pmGoogle seems to find many.E.g. Here:http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c64/http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c64/servicemanuals/C64-C64C_Service_Manual_314001-03_(1992_Mar).pdfhttp://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c64/servicemanuals/C64_Service_Manual_314001-02_(1985_Mar).pdf

author: rsjsouza
author_rank: Super Contributor
timestamp: August 24, 2020, 05:39:44 pm
content: Quite interesting talk, thanks for sharing the details RJ.Xevious was one of my favourite arcades when I was a kid back in Brasil (C64s were non-existent as they were impossible to clone by the local companies and imports were not allowed).Funny how people used to call it "Columbia" after the Space Shuttle - no idea why, given that "Xevious" was written in the main screen.

author: RJSV
author_rank: Super Contributor
timestamp: August 24, 2020, 10:13:46 pm
content: Wow, would you (mind) tell us more, I'm assuming that was circa 1982, with import control, can't wrap my thoughts around (that probable mess)?Oh, the crime potential, a C-64 costing $2500 US. ?Pls, or you may also start a cool thread, on arcade and personal electronics, then and there !!!Enclosed, less exciting, I did explore the C-64 speed up issues, and came up w a 'BANDWIDTH' thumbnail.(But, hey, my favorite Arcade Zevious version, my favorite was those rotating plates, out there in space)So, from that 'Code Tower' discussion, I felt efforts led to a 'asimtote' curve, of CPU speed doing basic block moves. Enclosed curve, that's the low (blue) curve shows the roughly 2 X speed, using 24 elements in-line rather than tight loop.Try just code toLDA blah blah,YSTA Scooby-Doo,Y*Etc just fill your code space. Then, max speed comes to about 80 kbyte per sec.Call that a Bandwidth type G.Came up with that using a crude est of 5 + 5 + 2= 12 micro-sec.Faster, I coded at 4 + 4 = 8 clocks, or usec.So that is the orange line.That graph gives some sense, of hard upper limits, on code speed. On the XEV game, est of screen block move and new tlles came to 70 milli-sec.... way too long for a 16.7 msec raster sweep repeat time.Then realized, the game has also 8 steps of scroll on hardware, that giving about 130 msec.That's where I came up with figure: 70 percent, of CPU clocks, for scrolling function.But brings up a video related question:Being a flat screen, HD laptop screen, who cares about (video) RF, or Baseband, anymore.?And does CRT raster friendly code mess up, w modern flat technology ?But I digress, let's hear some more about South America, 1980's... Thanks for that!- Rick-Jack

author: RJSV
author_rank: Super Contributor
timestamp: August 25, 2020, 08:43:42 pm
content: Tiles, and CompressionPhoto has one of the graphics screen sweeps, a moving display over the VIRTUAL and un-compressed playfield of the game. 120kbRecall, took 40 seconds before wrap-around, and a bland patch of scenery (design) kept seamless and varied fly-over looks. 64 tiles across, you can picture using 128 max from a pallet tool. So each tile can be a small 0 thru 60 range, easy. Later conversion is for physical address, into your storage. It was only, 1000Tile store area.Stamps, similar, used about 60, (they get tiresome) so you could observe the sys is under-used)So stamp buffer was also merely 1024 bytes.The 'world' playfield, was 64 by 64 tiles, however, each instance of Tile recreates 32 bytes on-screen.The 64 by 64 playfield list, is 4 KB, starts to impact the C-64 game, that product loaded, and ran with no disc access.STAMPs by clarification, are a pure software construct and tightly linked in format for copy, stamp bank to hires screen. Before, prev post example stamp and code to make a quick pointer 16bit.

author: RJSV
author_rank: Super Contributor
timestamp: August 26, 2020, 01:46:49 am
content: Adding depth of color, if can't speed up theTILE/STAMP sysIf use a full 256 stamp shapes, same speed, just will use 2k. Plus, any TILE will flip horz/very. So that is 1025 possible pixel forms.Creation system has to account for no mirrors, in the base stamps, for best.TILEs: Suggest 16 bytes per tile, 4 each, per stamp.Result is each stamp gets 3 colors, plus possible flips.Biggest tile can run thru 12 colors, figure 3 per 'stamp'The figure shows using 8 colors, 3 different ones, in each of the four stamps, or called 'cells' also.Figured 250 Million diff pixel sahapes...but this could make some great depth of colors, or rich-ness.C-64 has 16 colors

author: RJSV
author_rank: Super Contributor
timestamp: August 26, 2020, 05:42:37 pm
content: You could do a video-like repro, a smaller screen area at maybe 12 frames per sec. Using this same Tile and stamp system.Taking some 600 bytes, and 5 pages code, routine doing pixel copies is worth having flips, both Very and Horiz. So see following ex.:Backward Vert:LDY #7*LDA (80),Y. get sliceDEYSTA 4000,X. to screenINX. next hires screen pos"LDA (80),YDEY. nextAnd so forth, for each of 8 slices copiedNow, after BIT test finds flips:You use Y temp so have to keep reloadLDY #0LDA (80),Y. stamp sliceTAY fliptable will provide H flipLDA FLIPTAB2,YSTA 4000,X. to hires screen*Notice this above, gives both flips. Each variation writes to screen forward, vertically, but option to pull it out (stamp bank) 'upside down' and table translated horizontal flip is tedious.For example 0010 0000 becomes 0000 1000, in horizontal mirror. Bits are in pairs, so third place pixel swaps to be second place. Place that as a 08h, in line two of table...Obviously, some computing power is required, in pre-producing the 'video-like' display square, and don't be naive about the 16 colors, some are completely dorked! But consider, maybe 8 color shades...

author: RJSV
author_rank: Super Contributor
timestamp: August 27, 2020, 05:31:36 pm
content: Sourcing Dilemma:There are 4 billion pixel combinations, consider 4 by 8 and that's only single color. When 3 colors for choice then it's a huge num.So it's a Source Dilemma, just one stamp (8bytes).The stamp bit-pairs make for 'virtual' colors, future real assignment. But for now, called colorA, colorB,colorC, before actual assignments, from tile.In building an artificial set, it's hard to get past 60, let alone 100 stamps, manually. C-64 has a set.Once a stamp set gets to 150: You still have to come up with another 100 shapes, (and weed out any mirrors). On other hand, once start with all three colors the combinations multiply, rapidly using up the 256 range.Photo shows a tile, shows a more random-like approach does not do badly.The random and diffuse look, just as useful as a contrived shape, such as line or square.Needing an AI system, for building the stamp and tile set. The video-like player is 8 by 8 tiles, for 10 seconds, alternating two screens, 10 hz.That darn C-64 hires needs a big sys to feed it!

author: rsjsouza
author_rank: Super Contributor
timestamp: August 28, 2020, 02:17:53 am
content: Thanks for the details and thought process; it is not every day that one goes through the mind of a developer of that era.Quote from: RJHayward on August 24, 2020, 10:13:46 pmWell... Not much to tell. Imported finished goods were forbidden for the common man and only the very few lucky ones that travelled overseas could eventually bring something - either under tremendous stress of being caught by the port authorities, having some relative "in the know" or having some extra $$$ on the side.The market in the early 1980s was very fragmented and dominated by clones manufactured by several local companies: Microdigital (Sinclair clones, later Apple ][c and ][e clones), Microcraft (very well crafted Apple ][ and ][e clones, even created a McIntosh prototype), Prológica (Sinclair and TRS80 clones), Digitus (TRS80), and perhaps others that I don't remember. In the second half of the 1980s, large local electronics manufacturers Sharp and Gradiente started to massively dominate the market with MSX manufactured under license but, in the turn of the 1990s, import restrictions started to be slowly lifted and smuggled PC parts pretty much consolidated the market.History tells that the McIntosh clone done by Microcraft was its demise, since the Brazilian government forced the company to shut down after pressure from the US. This was triggered by Apple, which for years was trying to prove to the US government these clones were copying Apple's own ROMs - without a smoking gun, they draw blanks. When the McIntosh came, Apple inserted one innocuous "Easter Egg" in the code, to which the prototype also had and therefore proved they used their code.The Arcade market was not very different; there were probably many bootleg ROM clones, but these were harder to track as they had worldwide distribution. Of course, for the common kid/teen, purchasing one of these was completely out of reach. The pinball machines were different: all of them were conceptualized and created locally, with local themes, decorations, etc.Oh well... There are many other stories but I suspect I derailed this long enough. Back to normal programming.

author: RJSV
author_rank: Super Contributor
timestamp: August 28, 2020, 11:20:32 pm
content: Thank you. First tho, gotta pay the rent...C-64 TV (compression related)Photo shows the so-called 4 line DEMI-STAMP, where concept keeps an even smaller TILE and STAMP division.With a (hypothetical) larger /faster system 'crunch' down a sample video, perhaps a stamp (4 byis too big for getting multiple shape matches.The video 'sourcing' software would be looking for matches, or near-matches, in order to have repeat use (of basic pixel shapes).Also, along this subject line, it was realized: most natural videos may not contain much in the way of 'mirror' repeats. It is expected, that most cases, any repeated (stamps) having mirror shapes (vertical or horizontal) may be only a mere handful (compared with a main set of 256).So, imagine a 'crunch' software run producing two sets of Demi-Stamps, 256 in each set. Thus a tile, keeping near to discussed formats would simply contain pointers to 8 Demi-Stamps. Previously a more conventional tile would list 4 full stamps. The pointer can be stored, for direct speed-up.The photo, upper 4 lines shows a Demi-stamp wherepixels are further lumped, an example 2 X 2 pixel result.(green boxy areas)This is simply to illustrate, a final arrival, where a Demi-stamp set can fully encompass all possible (256) shapes, that's 4 colors, 2 by 2 pixels.Now going back to 4 X 4 a fully expressed set of pixels in a demi-stamp has 4 billion combinations (16 pixels by 2 bits each).Seems like actual C-64 color performance is not as pessimistic as the numbers suggested.It's the graphics sourcing that's going to be needed, to feed the ( existing) play system

author: RJSV
author_rank: Super Contributor
timestamp: August 29, 2020, 12:52:18 am
content: rsjsouza, that was good reading, had to slow down and repeat read. Mind boggling that amount of lack of hope? (A bad phrases, I know).In those times, I searched, a little. A 'phone' expert, I did support, for others remote. Very exciting, hmmm yeah I know. But sporadic hobbies were not enough.Friend said COMMODORE 64, when I babbled about a TRS80. Oh, why that one ?Anyway, ambition, and a new, 16 color C-64, and I quit those stout beers each evening.I like, also your mention, of arcades. Something tells me, I wonder some Japanese Co. often went to great efforts, to monitor if not visibly 'protect' a market.Several (bigger) players, I bet, had very good sources in distant lands, just for a sense of 'markets', no real action... That's maybe a mark of the play, so to speak:You don't see em.'Columbia', ha! Now, if you remember, was that an Atari-Games arcade? They looked like some generic Cabs, my neighbor had five or six, there in parking garage.RBI baseball ? Mechanical, and what gambling, if any were overt, there...Still amazed, I maybe w/b depressed, there then.

author: RJSV
author_rank: Super Contributor
timestamp: August 29, 2020, 09:48:45 pm
content: Mk14, thanks again, for the C-64 schematics and even more, the 'zimmers' links have block diagrams, and even a 'SAMS' manual reference. I always take seriously, time anyone spends on advice, so now had chance to view those C-64 tech notes / schematics.By the way, it was 'Programmer's Manual's that I had.But for serious side: THE MUSIC, XEVIOUS: here's how to 'sing' those two intertwined: PAY ATTENTION!Ok, you understand the melody, a four-note descending where (you) have to sing the clear notes, impairs."Duht duht, dotduht dotduht,daughtdaught, duut duut.Got it? That's the repeating clear notes.THEN, you simultaneously lay out that 'web', of higher freq audio 'beeps', (I guess). Approx 4 X faster, than the basic 8-note walk-down. Dawtle-eedle dutle-eedle, something along those lines. EXCEPT, you must, also modulate (your) cheeks, with the web of little beeps.The result is a two-part, sounding to me more like a cockpit or ship command center, rather than a music hall. That's where folks got off the track: it's not a song... It's an ambience, YO.Seriously, I can do it, the 8 descending notes, with the swirling 'peeps' and mouth cavity modulations, all around the descending note sound.Ok, enough of that. I bet you, too, can sound like XEVIOUS, (friggen irritating).Here is my 'stack' code, for a private 6502 stack, out of harm's way (used for various private code functions that won't crash BASIC loader etc.Rick_Stack:LDY 9900h. Stack at 9900-99FFSTA 9900,Y. PushDEY. next stack POSSTY. RJ_Stack. Place a def elsewhereRTS*Now, folks have a 'tune' to hum, whilst coding C-64

author: RJSV
author_rank: Super Contributor
timestamp: August 30, 2020, 11:22:51 pm
content: R.I.P. Chuck Peddle: Designer 6502 IC (MOSTECH).Some other XEVIOUS game detail, besides scrolling screen graphics:SPRITE Animator, code stack for close timing,. Jump table, programmer firewall;We (two principal progs) had a code ' firewall', just a crude set of time and mem space rules. Other guy had assigned (only) 1 millisecond for code run, then had to relinguish CPU control. Memory space wasn't that bad but I had to insist on graphics hogging most CPU clocks (that was a 15 millisec. window, each 16.6 milli-sec.). Reminds me, we got a second contract offer, to convert for 50hz screen operation. That meant more money (yippie), so now I walked w 'some' in pocket.(As you may have guessed, 8,000 $ was not a huge chunk, at least half year's work 1986.)So, but a main 'code separation' rule was: Other guy does almost whatever he wants. Handed over a disk w object code, every week or so. Gawd... I have no detailed idea what that other code did!The 1 millisec code module did ALL the gameplay / reading joystick in real time, playing the 'music' ,/ ambience noises, plus some really clever 'work arounds' re the C-64 missing documentation.For coordination, there was a Jump Table for major functions: that way each person's assembler process had working 'links'. Each code division used separate and differing dev tools, a large MSDOS sys kept the whole, objects and graphics.Shipping dept did data entry for artist and other files. (!!!) Yah, we were tight on avail time, Christmas sales season looming. USGOLD did UK distribution if recall correct.The Jump table was at 8000h (or 32k) I believe, mainly that helped by keeping (long) printouts from too often changing, as debug progressed.There were about 20 entries in the routine jump table, which could be kept stable longer. That helped, as for matrix, inside it's box, took over 35 minutes to generate another listing with hex locations for setting break points etc. I actually never saw, or even had time, for looking at my friend's coding work...plus a little scared what was there (!!!).Now, for one type of debug, I devised a 'stack', of no-op instructions:. These allowed a screen sweep start to be coordinated with code. By ajustment of entry, during de-bug the timing could be altered for avoiding a 'ragged' and flickering top line.(No extra print outs as the exact timing was tested in debug.)For Sprites, a medium complexity animation control allowed sprite PTR changes and sprite position changes timed for testing and tweaking. Mostly that was a list format, each set of new Sprite positions came on a time scale, using video frame rate as basic clock. Each movement / change came at 12 times per second, interleaved.Sprites being hardware, the position updates can be exerted very fast, like run thru a whole set of sprites in 2 seconds or less, all done at machine speed.Actually, don't recall if the code function jump table was used, even, by the 'other' partition code running.Overall, we kept at it, several managers had a cow, got nervous, started smoking again, etc.I've kept by my change of night-time habits ever since, which abandoned the STOUT BEER market, one side 'casualty' of ambition.That's what that Game dev was, for each of us.

author: RJSV
author_rank: Super Contributor
timestamp: August 31, 2020, 09:30:24 pm
content: C-64 HIRES MORASS, andmore clarity on extra stack========================For an extra stack: Many times, it's been overly difficult to sort-of, ELBOW a way into Page Zero (bytes).Looking at C-64 manual, it always feels like, maybe a couple bytes here, maybe 3 or 4 bytes there. (Even to the point of feeling like an 'intruder' (LOL).So, having a private stack can help, when not time-critical. Programmer defines a page elsewhere, like example 9900h thru 99FF h. First, one way is to store the index, at begin of the (extra) stack area. Again, this saves critical Page Zero spaces by avoiding use there.Also, while not fluent in 'C prog language' some C functions use a stack space allocation, a process of reserving a small block, say 16 bytes, on a stack.Let's start with that:RJ_Stack: EQU 9900 h. define the space lable*Grab_16:. Allocate tempLDA RJ_Stack. Get indexclear carry flag. (Forget how)SBC 16. Reserve 16 bytes tempSTA RJ_StackRTS. Now can pass parameters**Now, for example PUSH byte:Prv_StackPush:LDY RJ_Stack. Pick up current indexSTA RJ_Stack,Y. Push the accDEY. nextSTY RJ_Stack. Store the next empty byte ptrRTS*Of course, this is only partial outline, there must also be a de-allocation, and a routine to 'PULL' a valueNow onto the HIRES Morass, when pre-processing stamp set, for later play-back, onC-64.As a tool for thought, is the Demi-Stamp, and also having 'blocky' pixels (2 by 2). See photo. That gives a thumbnail for examining full conversion, without loss.Since each combination can be detected and reproduced, without excess processing, that is helpful.My choice, of a 4 line stamp, is also for increasing the likely-hood of many matches, for compression that the Tile/Stamp system can do (and must do, actually).Trying out the minimal case, avoids having to process screen pixels that are 'close' but not exactly right, a lossy case, as original info gets dropped for each pixel not perfect match.Of course, the full Demi-Stamp cannot be done 'lossless', as there are 4 billion combinatorial patterns, obviously not to fit into 1 byte (0-255).So, here's the morass:. Going back to the perfect cases, (see photo) each bit-pair is an indirect color ref.That is, no direct color assignment yet. Now you can see how, in the photo, there is more than one order, for the three actual color nibbles. As long as things track each other, in the one Tile, you can actually set it up SIX different ways: each having the exact same display screen looks. (I like to call those the 'Output' colors, where the bits and nibble locations are 'Logical' color.So, see how example RED is done, in two different ways, swapping logical places with Green pixel, while maintaining one to one tracks on actual visible Output on screen.There are six variations of this property, of using indirect references, with the bit-pairs.My problem here: Can't get a handle on what the size is, of the 'fully repeatable' screen dot pattern. ?And (even) further incomprehensible: How to maintain a coherent processing, when the encoder software moves on to other stamps and tiles. (The goal being to create a Stamp set, for later port to C-64 machine/ game.)A first approach, would keep each of 3 color nibbles in same order. But this can get complex fast, in the general case. For example, suppose your software pre-orders a few stamp indirect bit pairs, to match. Now, a next stamp has a new color, also potentially for finding duplicate stamps. One process is passive, while the active process converts (stamp bit-pair format and associated color nibble). The active processing could cause a multiple pass need, for best simplification or near- best of multiple and differing results.Example, maybe one process pass produced 17 near matches, while another had 9 near matches. But then another color involved suffers more (loss). So the judgement / weighing becomes important for best outcome. But right there, have to define what 'best' compromise means (for the actual screen appearance)Any help w this, appreciated!"...Don't like the CODES,...but the CODES like me.."--altered from Marilyn Manson lyricAn engineer's mind, sets on a problem, obsessed; that's what I mean.

author: MK14
author_rank: Super Contributor
timestamp: August 31, 2020, 10:06:30 pm
content: Quote from: RJHayward on August 31, 2020, 09:30:24 pmCLChttp://www.obelisk.me.uk/6502/reference.html#CLC

author: ebastler
author_rank: Super Contributor
timestamp: September 01, 2020, 03:48:15 pm
content: Quote from: MK14 on August 31, 2020, 10:06:30 pmExcept that, to prepare for a subtraction without incoming carry, you have to SET the carry flag.LDA whateverSECSBC #16STA whatever_minus_16

author: MK14
author_rank: Super Contributor
timestamp: September 01, 2020, 04:20:29 pm
content: Quote from: ebastler on September 01, 2020, 03:48:15 pmWell spottedEssentially a 'Reverse polarity' or Carry becomes a NOT Borrow flag, type of concept.http://www.obelisk.me.uk/6502/reference.html#SBCQuote

author: ebastler
author_rank: Super Contributor
timestamp: September 01, 2020, 04:36:11 pm
content: Quote from: MK14 on September 01, 2020, 04:20:29 pmThe way I think of it, subtraction is simply implemented as an addition of the 1's complement (EOR #$FF) of the subtrahend. The result is one less than what you want, so you need the "false" carry to fix it.LDA #16EOR #$FFSECADC whateverSTA whatever_minus_16Edit: EOR, not XOR -- let's stay true to the 6502 here...

author: RJSV
author_rank: Super Contributor
timestamp: September 02, 2020, 06:00:18 am
content: By way of finishing, thoughts on an available 'private' data stack, resembling 68000 / C language stack 'frames', or blocks:Assuming the block reserving code does the correct subtraction of 16 ,(thanks for help editing the proper CARRY use), the idea is a stack area as kind-of 'sacred ground', being essentially out of the way.So any subroutine, caught in the middle, can do a couple of temporary push/pop without concerns. Meanwhile, for example, there could be a Stamp fetch subroutine, taking a 4th byte as input: a Stamp number (0 thru 255). Then, subroutine calculates equiv pointer into Stamp bank, and reads (those) 8 bytes of hires pixel data, into the 'variable in/out' block.None of those actions changes the private stack pointer, but the calling routine knows the agreed convention, a block of 16 for communicating (with stamp fetch).A clever use of absolute-indirect makes for easy implementation:Initially, you place a 99 h into second byte of data stack:LDA #99. (or do it using assembler lable/256 )STA RJ_Stack + 1 See also, prev posts*JSR Grab16_prvstack. Allocate blockJSR. Fetch_StampPix. Read out stamp bit map** etc etc.*Fetch_StampPix:LDY #12. Stamp num in 4th byte of 16 blockLDA. RJ_Stack,Y. This gets 9900h + 12 is numJSR. Convert_ toPTR**. PTR held in byte2 for example format*JSR Copy_EightSlices*. now the 16 byte stack block has full stamp"* etc etc to screen etc* now done w special block-frameJSR. UnGrab16. De-allocate the temp parameters**So, you can see, any other little subroutines, along the way, here, can transparently do a few Push/Pop cycles, using same private stack, without conflict.*AND..., This time the stack index gets,CLCADC #16. De-allocate the block

author: RJSV
author_rank: Super Contributor
timestamp: September 02, 2020, 06:09:16 am
content: .,.oops, I meant read indirect:LDA (RJ_Stack),Y. This contains 2 indexes, one for pointing to block, other into element 4th...same as LDA (99xx),Y uses 2 bytes at start of the 99 page

author: RJSV
author_rank: Super Contributor
timestamp: September 02, 2020, 06:47:00 pm
content: BEGINNERS and Casual Readers NOTE:Clarity and correctness being crucial, don't hesitate to complain! Myself, I tend to tune out, if presented with piles of unexplained code strings...So here are more details, for coherent presentation.Pls SEE PHOTO DIAGRAM of the private stack and allocated BLOCK :. More advanced readers note, I may have garbled the ALLOC function meaning, in C prog.Viewing the page used for an extra data stack, the very bottom holds the single byte stack 'pointer', with option for using in 16 bit form. Mainly, there is no indirect load, generally outside page zero, a simpler 0 offset. For more info, you can see JMP on 6502 CAN do this, but for loads and stores, you have an index reg added, to offset the final (address).Main access to the 9900 thru 99FF stack is using the single byte, as in LDA (9900),Y. where Y has been loaded first, from 9900h.However, for access to the allocated block of 16, then both bytes, down at 9900 and 9901, are picked upsimply by the instruction,LDA (9900),Y...that uses both bytes there. Then, index reg Y is used for offset access into the pointed to block. In this example the 4th element is the interest: that being an ID number (stamp ID = 16 or 10h).Each sub-part of the code works starting there, creating a real physical pointer, by multiplying and by adding to the stamp bank base (8000h).Then, a pixel fetch sub- part gets/puts actual pixel holding bytes, slow running speed is OK for editing tool. Note however, the rendition was upside down!You can see a shape, in green ink, of a corner resembling the letter 'L'.If explanation is followed, reader will arrive at the relative addressing rather than hard-coded method, thus allowing more flexible-local references (only).Any pixel fetch routines don't know, or care about literal locating of processing targets.Probably still confusing, but I try answer any direct questions: more advanced folks maybe bored silly (lol).The ZEVIOUS C-64 conversion, well much of the work skill was not stellar. (We keep learning too, so...)Rick-Jack

author: RJSV
author_rank: Super Contributor
timestamp: September 02, 2020, 11:03:41 pm
content: I'm also starting a new thread:"SEE 64 TV"Searched a bit, and no ' trademarked' stuff, ...just a side reference, to some Trolley Line, in the UK...( They better not sue me, have to sell the DeLaurien,if they sue, for trade infringe)See the water-cooled rendered pict.)