Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 07/22/21 in all areas

  1. 29 points
    Hello Everyone! I received the parts for the third Prototype on Tuesday evening and spent a good chunk of that night and a bit of yesterday morning getting it worked out. I had to get my code moved over to the ATTiny861 before the board would even power on. This turned out to be pretty easy now that the I2C header will also work as an Atmel ISP programming header. Of course, I'm pretty much going to make a mistake somewhere on a board of this size, and this time is no exception! Fortunately, they were easy to spot and the actual logic is working as it should. Or at least as I designed it. Two of my mistakes are visible in the pic, see if you can find them. One is just cosmetic, and the other is a bodge job on a chip which I will admit, is next to impossible to see in this photo. The less easy to spot issue is that I used the stand-by power to power the microcontroller, but I put pull-up resistors on the I2C lines (and SPI programming lines) to the system voltage and not the VSB. I did this on purpose as I didn't want to pull these lines high while programming the microcontroller, but need to pull them high for I2C. The net result is that leakage was happening backwards through these resistors when the data/clock lines were high. Enough to power on the LED on the motherboard with no other ICs plugged in. Took me a minute to figure that one out, but I think I will just throw a few more diodes in to protect this from happening. I suspect issues like this are sometimes why you may see a lone crusty resistor on an old PCB after years of use. Easy fixes all around! One last issue is that the parts sourcing scourge which has been affecting the world is also affecting TexElec! Yes, we can't get parts in for some of our products, and as time goes on, it seems like it may get worse before it gets better. And now, it has hit the X16 project! I am unable to get the FPGA and the DAC for the new Version 4 VERA, so we're still running V3. The main difference has to do with hardware deadlocks on the SD card, so functionally, it's fine. However, the lead times are a bit concerning. I'm looking into some other suppliers now, and hoping for the best. For now, here's a pic of the new machine, with no wires all over it! Take care! -Kevin
  2. 4 points
    Scott! Wowzers! That's amazing to think about! Of course, there's already a lot of this sort of thing in 'the other direction' in the retro computer community. I have to take great care not to be a jerk when I see someone post on REDDIT about how their brand new VIC20 game blows away anything that ever existed at the time the machine was 'in general use' and how the original programmers must not have been any good etc., etc. Of course their new VIC20 program was put together using a cross development environment running on a modern machine with more than half a million TIMES more transistors; repeatedly (and instantly) compiled right into VICE or whatever emulator of choice for testing. The graphics were prepared using photoshop and illustrator and other utilities (having a combined code size equal to many thousands of 1541 disks); and thanks to the internet, with the benefit of having access to code libraries and disassembled code from virtually every 6502 based game app demo etc ever made! And don't get me wrong I don't begrudge folks from using those 'best available tools' for the job. But its the smug and self righteous comparisons in which they credit themselves as better programmers than the folks from 'back in the day' that tends grind my gears. I wonder what their game would have looked like if they HAD used only the same tools as the people who were programming on the old machines in the 1980s, using simple assemblers, graph paper and colored pencils for the drawings, and (on the VIC20 at least) saving their work on cassette tapes (where just the 'save' gave you time to go out and get a cup of coffee). Geez. See what I mean? I can be a real "get off my lawn" old coot when it comes to that topic!
  3. 3 points
    https://blog.davetcode.co.uk/post/21st-century-emulator/ My favorite / most horrifying part: (just to be clear, they're not serious)
  4. 3 points
    But popping a 65816 into the CPU socket won't add the "one extra chip", because it has to be in the motherboard. Popping a 65816 into the CPU socket in effect gives you a 65802 with slight bus incompatibilities (SYNC is replaced by VDA/VPA and IIRC the clock outputs are DNC and a reset input). And a bus mastering 65816 card would be pretty much the same thing, though more room for circuitry to bridge the bus incompatibilities ... including masking out the bank address from the data lines. I would be entirely unsurprised if the problem in writing VERA is the bank on the data bus followed by the data confusing Vera in a way that is not an issue with the 65C02 write cycle. Nor would I be surprised if the bus cycles for some of the chips "work" with the 6502 but just make it, and small variations in actual read or write delays associated with the transition between bank mode and data mode make the timing too tight to work. But if you can get a bus mastering card to work, you get the pcode interpreter with the accumulator in 8bit mode and indexes in 16bit mode, with ops ending with JMP NEXTOP or an eight byte NEXTOP macro: NEXTOP: INY : LDA 0,Y : TAX : JMP (OP1,X) The thing is: since it can run 6502 assembly code, can run the same pcode as the 6502, except faster, and can host a compatible ROMBASIC interpreter, except faster, and since assembly code can test whether it is running on a 6502 or 65816, it might actually work as a 3rd party enhancement. Then it would only breaks running CX16 code if people use any of the four individual-bit-addressed operations in their assembled code, so it just needs "enough" of an install base so people shy away from doing that.
  5. 3 points
    16-bit rotations are easily doable without loops because the bit that rotates “off” the register rotates into the carry flag, and the carry flag rotates into the register. so say you have a 16bit unsigned variable held at myword, and you want to multiply by 4. ASL myword ROL myword+1 ASL myword ROL myword+1 Do it a third time for myword * 8. ASL always shifts a zero into the LSB. ROL shifts the carry bit into the LSB. (that’s why it’s ASL on the low-order byte) so to finish your formula, after the three shifts: LDA #$10 CLC ADC myword STA myword LDA myword+1 ADC #$FC STA myword + 1 This can be done more efficiently but I wanted to use the most straightforward methodology as the example.
  6. 3 points
    Though it doesn't have to be future proof ... it's only a bridge until R39 becomes the baseline release. That's the part that has me in suspended animation ... I am not interested in putting code into a version test that I am going to want to strip out again once R39 is the public release.
  7. 2 points
    This is the fastest routine I can quickly think of: LDA semitone ; not counting this as this has to happen no matter what alg is used CMP #9 ; 2 cycles BCS @add3 ; 2 | 3 cycles CMP #6 ; 2 BCS @add2 ; 2 | 3 CMP #3 ; 2 BCS @add1 ; 2 | 3 BRA @add0 ; 3 @add3: INC ; 2 @add2: INC ; 2 @add1: INC ; 2 @add0: ORA octave ; 4 ; assume octave is stored pre-shifted into 4 msb STA keycode ; same as LDA semitone So the number of cycles is: 2 + (9|11|13|13) + 4 --> average of 17.5 cycles - so let's call it 18 cycles. a lookup would be something more like: LDX semitone LDA kc_lut,X ; 4+ ORA octave ; 4 STA keycode So twice as fast, requiring 12 bytes of RAM. Given that this operation doesn't happen super-often (pretty much only up to 8 times per frame?) I'd call this "pitayta-pitatta" / "six in one hand, half a dozen in the other" / pick your idiom. In the end, 12 bytes of RAM ain't much to sacrifice, plus the code's a lot easier to read, too.
  8. 2 points
    I finally got around to installing BMCBM (okay, it's called BMC64, but I think it should be rebranded to BMCBM given that it includes five different machines in one package). It booted up to the classic C64 in PAL mode. I switched to NTSC (since I'm in NTSC land) and C128 mode and I finally have a C128 again. I've done very little with it, mind you, but at least I can see it boot and can write little programs on it, as well as switch to C64 mode to play my games that were never ported to C128. Now I just have to dig around more into the settings to figure out what I can and can't do relative to a full blown Vice installation on Windows.
  9. 2 points
    Yes, the sprite data should already be in VRAM. The sprite attribute table at 1FC00 will point to the start location of the sprite data in VRAM. I found @SlithyMatt's sprite tutorial on YouTube very helpful.
  10. 2 points
    So, the Opening Ceremonies for the Tokyo Olympics aired this morning (in my region) and is about to be repeated. If you hadn't heard, the "Parade of Nations" sections where all the athletes enter the stadium in groups behind their respective flags, was entirely underscored with (arranged) video game music. At first I recognized Dragon Quest (Dragon Warrior in N.A.), Final Fantasy, and two tunes from Chrono Trigger, and two others that sounded familiar but I wasn't sure where they came from. I thought they had worked some video game tunes in with other music. But, later I was able to read that all the music in this section was from video games (all by Japanese composers, of course). The two I couldn't place turned out to be from more recent games, Monster Hunter (which admittedly does have a nice theme) and Kingdom Hearts. I haven't played those but I must have heard the music somewhere. The Japanese seem to have responded very positively to this. Japanese twitter was full of people declaring that the main Dragon Quest theme is Japan's "Second National Anthem." This isn't surprising: when Enix first started to make Dragon Quest, they hired mostly young up-and-coming professionals (like character designer Akira Toriyama whose "Dragon Ball" manga had only been in publication for about a year when he was hired by Enix). But the composer, Sugiyama Kouichi, was already considered an elder statesman of commercial music and was well-known for television music in Japan. Getting an older, established name attached to this project in a new media by a new company of mostly young people was quite a coup for Enix. The popularity of the DQ theme in Japan went on to far surpass any of his previous works. For me personally, hearing video game music in general, and some of these compositions specifically, as a kid was a big part of what inspired me to become a musician. I felt like video games were still 'nerd culture' back then and that my friends and I who spent hours playing them were living in a different world from the other kids who were involved in sports. So, hearing these tunes at a sporting event (the Olympics) actually felt really good; our worlds of interest are relevant to each other. It's also just nice to see Japan recognize that their video games are an important part of their cultural identity and of the way they present themselves to the world. This link has a list of all the game used (in Japanese): hochi news And, here's my best, quick attempt at a translation of the list. However, there are some character names I don't know, from the games I haven't played. Dragon Quest [Dragon Warrior]: Loto's [Erdrick's] theme Final Fantasy: Victory Fanfare "Tales of..." series: Sorey's theme Monster Hunter: "Mark of the Hero" Kingdom Hearts: Olympus Coliseum Chrono Trigger: Frog's Theme Ace Combat: First Flight "Tales of..." Series: The Royal Capital Monster Hunter: "Wind of Departure" Chrono Trigger: Robo's Theme Sonic the Hedgehog: Starlight Zone Winning Eleven: eFootball Walk-on theme Final Fantasy: Main Theme Phantasy Star Universe: "Guardians" Kingdom Hearts: "Hero's Fanfare" Gradius Nemesis: Act I-1 NieR: Song of Initiation[?] "SaGa" series: "Song of the Demon Bard" [??] (SaGa series medley, 2016 Orchestral arrangement) Soul Caliber: "The Brave New Stage of History" EDIT: Notice, none of the games included were made by Nintendo (though some were for Nintendo systems). So my prediction is, there will probably be a Nintendo-themed segment in the closing ceremonies.
  11. 2 points
    Exactly! I once computed the number of disks that would be required to emulate a Windows 10 system on a C= 64 with 1541. Let's see, the computer I'm using right now, assuming we could even fit a CPU emulation in a C= 64 without having to swap programs in and out of the address space, would need 16 GiB for RAM and 951 GB for the SSD. So let's call that 902 GiB. I can store 166 KiB on a 1541 based on 664 blocks free (I'll just assume I read and write individual blocks rather than use files which would consume two extra bytes per block, and any overhead I can squeeze into otherwise unused directory sectors). So I'll need almost 5.7 million floppies just to emulate the RAM and SSD. Undoubtedly I'd need more to emulate other aspects of the system such as video RAM, CPU cache, etc. I wonder where I can find 5.7 M new old stock floppies? Or we could go really old school and use tapes!
  12. 2 points
    hi all! just signed up. In the eighties I played with Apples and Atari STs and nowadays I do inventory / MRP software work in Seattle. the X16 looks like it will be fun to develop for...just based on the dorking around I did today with the emulator, it really hits that "call to explore" mark. nice work everyone! gotta say it was surreal to copy BASIC2.0 source code from github and paste it into the emulator and have it work instantly .. if only the Compute! programs I typed as a kid worked out so smoothly.
  13. 2 points
    Google presented nice retro game as a doodle: https://g.co/doodle/99dkzef
  14. 2 points
    Awesome! Kevin, I'd say not to hesitate to lean on the community too: If you have a particular list of things you need (FPGA etc) to get proto stuff done, post a list and let folks see what they've got (or can leverage connections to get). Obviously it won't be the endgame supply chain, but if you need something (e.g., to get VERA4 onboard and rocking) it could be the hive mind might be in a position to help. As for myself, er... well, I've got a big bag of blue LEDs somewhere around here. In all seriousness, thanks to you and everyone on the team for plowing through all the things with COVID, the global supply chain weirdness and the online bikeshed factory to get things so this far. Can't wait for the next steps!
  15. 2 points
    Your mindset seems really sensible. Even if further tweaks are necessary, a release would take the community off 'pause' (avoiding any potential fall off of enthusiasm), and also acknowledge the value/importance of the work by the team members who have put so much time into the updates from r38 to r39.
  16. 2 points
  17. 1 point
    We've seen the videos. We know it would be like starting over, because the system only works at 8Mhz. Paul Scott Robson: Kevin Williams: Stephen Horn: Various people: But. Paul's argument haunts me PROBABLY ONLY because I am not a good assembly language programmer: With a faster processor, I could write a reasonably performant P-Code interpreter. We could write Robotron (et al) in C, or a kind of Commodore-friendly STOS BASIC. And keep everything else we've got. (Theoretically) What Paul is saying is EASE OF USE goes up by an order of magnitude, IF processor capability improves.
  18. 1 point
    I've read through this topic, and I've come to the same conclusions as I do with many 'programming language' discussions. The people saying the most and shouting the loudest aren't really the target audience. They aren't thinking about others, but about themselves and how they progressed as programmers. They think about what they know and use now, and they want to shape everything to fit in with that. They forget that some people have absolutely no idea of what programming is and need to learn everything from scratch. The absolute basics of programming... learning some simple commands, breaking a problem down in to steps, linking them and getting results. Understanding concepts such as variables, loops, counters and simple logic. Most people don't want to be professional programmers, they may not even want to be "good" programmers. They just want to dabble their toes in the water, experiment, have a bit of fun and see where it takes them. Or maybe just get a pleasant dose of nostalgia. Would you teach somebody to read by starting them off with the works of Prof. Stephen Hawking and perhaps some Tolkien? Do you teach people to count by dropping them straight in to calculus, trigonometry and statistics? Probably not much fun for intermediates, never mind absolute beginners. When you start thinking about being productive and suggesting modern languages, you are clearly missing the point... this is a retro 8 bit platform. Most people already have a PC/Mac for serious stuff. If they wanted to learn 'serious' programming and be 'productive', they are hardly likely to choose this platform are they? Dartmouth BASIC was originally a simple language for students who wanted, or needed, to solve problems, automate calculations or some other process, without having to spend years learning computer science and complicated programming languages. It was ideal for that, and it still is. Nearly all the '80s micros had extended and improved versions of Basic available. Atari, Sinclair, Amstrad and CBM 8 bits had loads. COMAL was essentially an extended, structured version of Basic. They were all easy to learn. Had someone showed me C, Java, Fortran, Javascript or even Pascal as my first experience of programming, I would never even have bothered trying. The Sinclair ZX81 had a wonderful manual to introduce simple programming concepts to 14 year old me, as did my old Atari 400. That led me on to more complicated things, and now I actually like Pascal, and think Psion's OPL was a great little language to mess with. To me, the rest are overcomplicated, hard work and not much fun. There's that word again "FUN". Funny eh?
  19. 1 point
    #include <cx16.h> ... VERA.control = 0; VERA.address = address; VERA.address_hi = 1; VERA.data0 = the_byte; It compiles to the same Assembly code. But, it looks more C-like, less BASIC-like. cc65 also has vpeek() and vpoke() functions. They directly touch VRAM and internal registers.
  20. 1 point
    I assume you know all about The Guardian Legend and Battle of Olympus
  21. 1 point
    Seems you can, I got this from mesi on Prog8's Github: I will go and try that
  22. 1 point
    That's one thing I have doing a lot of lately, looking for games I missed back when they were new. Reading a lot of "Top 10" lists of obscure or "hidden gems" for various systems. It's quite fun to discover and play a "new" old game! Also discovered some games, a few recently on the TG-16/PCE, that were listed as Japanese but are in English. So I skipped over them when I first seen them. Or they were shooters where the language of the text is not nearly as important. And of course, translated hacked ROMs. Like I said earlier, I spend more time on my $35 Raspberry Pi than on my MUCH more expensive high-end "gaming" PC. lol
  23. 1 point
    I like that Mario Bros. clone. It reminds me of what I had posted in a different thread. Nintendo themselves did this with our version of Super Mario Bros. 2. The Japanese Mario sequel was deemed too difficult for the international market, so they took a game called Doki Doki Panic, and modified it to be the version of Super Mario Bros. 2 we know today. It's an interesting story. From Wikipedia: I do love how they add so many clones and ROM hacks just to get the count up. I mean, you know they are not paying licensing fees to sell the legit ROM's they are using, so why not just use all original games. I guess 620 in 1 looks better than 100 in 1. Still, there are hundreds of good NES games without the need for hacks and clones. lol All in all it seems like there is a good mix of legit ROM's in that NES clone for the price. Funny to see games like TMNT and others in a different language, even though they were also released in English. Being an import, it's fully understandable though. Also, that Street Fighter 2010 game, I loved back in my NES days! Played it a lot. Hard, but fun. I remembering being impressed by it's graphics. Good times. Great video!
  24. 1 point
    Yes, it also supports the ON ... GOSUB N1, N2, ... construct.
  25. 1 point
    Welcome. I was in Phoenix in the 70s and 80s and remember Scottsdale.
  26. 1 point
  27. 1 point
  28. 1 point
    Sounds like to me, if you did that, you'd be halfway to a complete game engine... Well, maybe 25%, but still.
  29. 1 point
    But it's not about Ease of Use, because this is what I expect would happen: Tom: Capability is expanded into a full 16 bit system, and this probably ceases to have that particularly Commodore simple-retro draw.
  30. 1 point
    Here's my attempt to make side-by-side comparisons of the Commander X16, C256 Foenix, and Mega65: Commander X16 C256 Foenix Mega65 CPU WDC 65C02@8.192Mhz WDC 65816 @14.28 Mhz, Choice of extra CPU Options (256 GEN-X and Above, not relevant to this comparison) Custom FPGA Core based on the MOS Technology 4510@40 Mhz System RAM 560K Standard (48K Low RAM, 512K High RAM), Maximum of 2 MB available by populating all RAM sockets. Memory Map presumably can address up to 2,112K Total Up to 64MB Standard (System can address no more than 8 MB on 65816 power alone), 2 to 4 MB on Foenix U/U+. 512K Standard, Maximum of 8MB available by populating all memory slots, CPU possesses 28-bit address bus, capable of addressing up to 256MB GPU VERA, Separately Addressed Video RAM, 128K (Memory resources shared with PSG and PCM audio subsystems) (*) VICKY II/III, Separately Addressed Video RAM (4MB VICKY II, 8 MB VICKY III) VIC IV, Video RAM Space within larger System RAM can be remapped up to 3 MB, but is mapped to 384K by default in Mega65 Mode Resolution 320x240 (256 Colors Tile, 1024 Colors Bitmap), 320x480, 640x240 (64 Colors Tile, 256 Colors, Bitmap), 640x480 (16 Colors) 320x240, 256 Colors (65536, VICKY III) 400x300, 256 Colors (65536 VICKY III) 512x384, 256 Colors (65536, VICKY III) 640x480, 256 Colors 800x600, 256 Colors 1024x768, 236 Colors (VICKY III Only) All resolutions from VIC-20 and Commodore 64, Plus 360x288 (1024 Colors 256 Color Sprite CLUT) 400x300 640x400 720x576 800x600 (@) Sprites Maximum of 128 4-bit pixel (16 color) or 64 8-bit pixel (256 color) sprites. Sprite size programmable up to 64x64 pixels. Maximum of 32 sprites per scanline (16 8-bit pixel) Maximum of 64 32x32 pixel sprites. No Scanline Limits, bit width per pixel unknown Maximum of 2048 4 bit-per pixel sprites at stock memory configuration in Mega65 Mode. Sprite size programmable up to 32x32 pixels, but defaults to the stock Commodore 64 12x23. Maximum of 32,768 sprites when all memory slots are full Fields Maximum of Two Tile Fields, or one tile and one bitmap. Bitmap field lacks scrolling registers and must be scrolled through CPU power alone, but is split into quadrants each with a separate CLUT Maximum of 4 Tile Fields and 2 Bitmap Fields Choice of one Tile or Bitmap Field through conventional means, but judicious use of the Raster Rewrite Buffer can permit an arbitrary number of apparent scrolling fields. Other Features VideoDMA with Blitter Functions, Enhanced functionality and bandwidth in VICKY III DMAgic Video DMA+ Raster Rewrite Buffer effectively produce two different extra blitter methods at the same time Master Palette 4096, four bits each of RGB 16,777,216, eight bits each of RGB 8,338,608, color generation scheme unknown Sound Chips Yamaha YM2151+YM3012 DAC, 8 Channels FM Synthesis, 4 operators, 4 possible waveforms, 16 Channels Geometry Synthesis, 4 possible waveforms 1 channel 16-bit PCM synthesis, 48 KH maximum sample rate, 4K audio buffer Yamaha YM2151+YM3012 DAC Yamaha YM2612, 6 Channels 4 operator FM Synthesis Yamaha YMF262 (Several different modes of FM Synthesis + available 5-piece percussion set), Texas Instruments SN76489 (3 Channels general Geometry synthesis, 1 channel sawtooth and white noise) X2 Gideon SID Core (6 channels total geometry synthesis, multiple filter options)+ socket space on the motherboard for two physical SID replacement chips, Red Box (CD Quality) CODEC X4 SID Softcores (12 Sound Channels total), two based on the original Commodore 64 version, and two based on the Commodore 128/Later 64 version, four available sockets on the motherboard for physical SID replacement chips. Yamaha YMF278 (FM Sound Channels from YMF262+24 PCM Channels with 16-bit sampling@44KHz, based on the Yamaha YMW258-F/Sega Multi-PCM, Successor to the SegaPCM chip used in several Sega arcade games, used in the Yamaha SoundEdge PC Sound Card and the MSX Moonsound expansion cartridge) I/O VGA Output, A/V Multi-out, PS/2 Keyboard and Mouse, X2 7-pin Super NES controller jacks with headers for 2 more on the motherboard for an expansion backplane, Commodore-styled User Port (electrical profile based “mainly” on the Commodore 64/128 version), SD Card Slot, X4 expansion card slots, based on the Apple II Standard Varies by form factor. Mid-Tower and Full Tower Backplanes have: VGA Output, A/V Multi-out, Single-Link DVI Output, PS/2 Keyboard and Mouse, X4 Each Atari CX-9, 7 Pin NES, and 7 Pin Super NES controller jacks, SD Card Slot, X4-6 expansion card slots, physical, electrical, and protocol set profile currently unknown VGA Output, A/V Multi-out, SCART out, X2 Atari CX-9 joystick Jacks with two extra headers on the motherboard for an expansion backplane. X2 USB 1.2 Ports, Commodore User Port (Electrical Profile based on Commodore 64/128), Commodore 64 Cartridge Slot, Commodore Floppy and Datasette ports, X1 3.5” Floppy Disc (&) Form Factor Horizontal Upright, Separate keyboard optional. Smaller form factor models projected in the future Choice of Bare Motherboard, Small Form Factor(roughly Intel NUC/Mac Mini sized), Keyboard Console, Mid Tower, and Full Tower Keyboard Console OS Kernal + Commodore DOS, GEOS GUI Unknown OS for 65816. Motorola 680X0 processor upgrades offered with choice of EmuTOS+FreeMINT or Microware OS/9. x86 processor upgrades offered with DOSBox+ReactOS, ARM upgrades offered with choice of some sort of Linux distribution or OpenRISC (%) Kernal + Commodore DOS, GEOS GUI Built-in Language Microsoft BASIC 2.0+additional reserved words and syntax revisions to take advantage of the hardware Unknown BASIC interpreter Based on Commodore BASIC 2.0 Commodore BASIC 10.0, Mega65 BASIC 11 for Mega65 Mode. Also not that I did not list prices, because all price quotes are currently preliminary. Notes: *: VERA's 128K of Video RAM is the FPGA's fabric cache. Video Memory cannot be increased. @: the VIC III 1280x200 and 1280x400 resolution modes of the Commodore 65 are not supported due to a lack of availability of Commodore 65-spec CRT monitors, and the rarity and expense of 2560x1600 5:8 aspect fixed pixel monitors. &: Two Atari CX-9 Commodore 64 Mouse protocol/USB dongles allegedly packed in % Full Compatibility with classic MS-DOS software stack and classic Ad-Lib and SoundBlaster support not guaranteed with x86 processor options. Full compatibility with Atari TOS/MINT software stack with 680X0 CPU option not guaranteed. Full Compatibility with classic Acorn Archimedes/RISC PC software stack not guaranteed with ARM CPU option.
  31. 1 point
    Russian speaking (though Ukrainian by origin) project "sinc LAIR" now in English and presents first translated video about Sinclair Pandora Project Z88: https://odysee.com/@Sinc_LAIR:3/The-Last-Sinclair's-Computer----Pandora--Project--Cambridge-Computer-Z88 Original YouTube channel: https://www.youtube.com/channel/UChC1Gcl-1bOkNPPzN_owcVg Patreon: https://www.patreon.com/sinc_LAIR
  32. 1 point
    Is the specification of the V4 VERA the same as before?
  33. 1 point
    I'm assuming it is related to Michael Steil (aka mist) who is working on the kernal. There is a four byte signature in the source code, though I don't find it at $FFF8.
  34. 1 point
    This thread actually is about the mainboard version, not the Kernal version. This is the easiest way to test it, and switch to the Kernal bank: ; Assume BASIC ROM bank 4 at this point. stz $01 lda $FFF8 ; BASIC has zero, Kernal has nonzero bne mb2 stz $9F60 mb2: "stz $01" changes that location, but does nothing else, on mainboard #1. It changes to Kernal's bank on other mainboard versions. $FFF8 is a part of Kernal's "mist" signature. But, it's zeroes in the BASIC bank.
  35. 1 point
    THANK YOU Kevin for the update! Even when there's not much to say, updates are a heartbeat, you know? And then there's these BIG updates which are just plain interesting, and as ZeroByte said, exciting even. The hardware shortage "only getting worse" sounds ominous... but I suppose that ought to simply be taken and used as an opportunity to examine the system as it is and think about it.
  36. 1 point
    That is understandable. I did the following to make a coming clean-up easy: The Kernal version is read at program startup. The control addresses for RAM and ROM select used by the detected Kernal version are stored in two zero page words In the rest of the program I read and store bank selections using these zero page words, like "STA (RAM_SEL)" When R39 is official, it's easy to do a project wide search and replace "(RAM_SEL)" with "RAM_SEL". RAM_SEL would then just be a definition pointing to the control address. But just a few minutes ago @Kevin Williams announced that prototype #3 is working more or less. Maybe R39 is not too long away...
  37. 1 point
  38. 1 point
    I couldn't agree more.
  39. 1 point
    I'm sure there are lots of behind-the-scenes reasons why this hasn't happened, but would it be possible to get someone to push the "R39 = official" button on the Github repo? My R39 workarounds include doing some manual things because cc65 gets broken on R39, and there are other tool chain projects like Prog8 etc which are also in limbo until this major revision gets officially blessed. I'm intentionally keeping my tools frozen as long as R38 is the official version, and I've read posts here and elsewhere by those who are ready to merge updates into cc65, etc.
  40. 1 point
    I don't have much to show for it yet but I did start work on the copy/paste - or more specifically the block selection routines. CMD-B and CMD-E now mark the start/end of the block and I have started work on highlighting the blocks in the pattern view itself. I plan on getting all that working before I tackle operations on the block. Marking the start/end of the block is easy enough - but drawing the highlighted area is much less trivial. This is partly because a single pattern doesn't fit in VRAM so when moving around channels, the blocked area has to get redrawn depending on what part of the pattern is in VRAM (specifically VRAM can hold all the rows, but not all the channels). To solve this I'll probably have a function that evaluates the start/end areas and highlights any part of that currently in the view which I can call whenever I need to. This is all to mark a block. Once a block is marked, I'd like to have multiple commands to operate on the block. This will include copy/paste but also can include other things like changing the octave of all the notes in the block, or inc/dec'ing the notes, etc. The copy/paste itself is still a bit of a mind exercise but I'll worry about that once I have block selection actually working. Another change is I broke the edit_pattern module out into sub-modules of its own, as it was getting pretty hairy having everything in one big file. I like this approach and will be breaking out the other routines into separate files to break up edit_pattern more into bite sized chunks.
  41. 1 point
    Hey johnzo! I'm also in Seattle! Welcome!
  42. 1 point
    I've played with my new The C64. It's not bad. Either the lag on the USB joystick makes games I used to play harder, or my age. But I don't feel older most of the time, so it must be the hardware.
  43. 1 point
    Let's be evil and make BASIC support pointer passing by naming a variable &V, &V$, &V%
  44. 1 point
    I never felt that the YM was in question ever since the successful demonstration of 8MHz bus compatibility. The SAA and AY PSGs were always on the bubble, so to speak, and as soon as VERA PSG was announced, I knew those chips were goners.
  45. 1 point
    When I look at the latest board just posted a few hours ago: We can find a socket labeled "YM2151" at the bottom right. So I'm pretty sure the YM2151 will be in the final design - as is the VERA PSG/PCM. Personally I'm pretty pleased with that .
  46. 1 point
    Music Player Library for BASIC Programs View File I wrote a library to enable BASIC programs play music in the background. It is compatible with Simplest Effects Sound library I released a while ago. To demo the library I included two BASIC programs: PLAY.BAS - Playing Twinkle Twinkle Little Star - it demonstrates the BASIC program doing other stuff including calling simple Effects HOUSE.BAS - Playing House of the Rising Sun - it demonstrates a bit more complex music Full Tutorial and source code is available from my blog: https://www.8bitcoding.com/p/music-player-library-for-basic-programs.html Submitter DusanStrakl Submitted 01/09/21 Category Audio Apps  
  47. 1 point
    One of the problems retro computers have is trying to connect them to modern TVs. The standard nowadays is HDMI, a very complicated digital protocol, that’s quite complicated to handle (it was discarded from the X16 for this very reason). Well, turns out that if you have an RGB signal, there’s a chip that can take that and create and HDMI signal, it’s the CH7035 by Chrontel http://www.chrontel.com/product/detail/35 If you need to add HDMI output to a project, keep it in mind. I found it really interesting. Hope you find it useful.
  48. 1 point
    I didn't even notice the brand. That's pretty great. And I do like your ergonomics better. I'm not a fan of low profile/low travel keycaps. It's the one reason I'm probably not going to buy a Pi 400... I'm waiting for the inevitable mechanical keyboard case.
  49. 1 point
    I was suggesting doing both If you work through Ben Eater's 6502 course (I've only skimmed it) you won't have much of a computer but you'll learn a heck of a lot. Then progress to a machine like the X16 and you should be able to see the links between what you learnt on the first course and what the X16 is doing. Though you'd have to view Vera as a "magic box" I think. That's basically what I did, I started with an SC/MP trainer board and then had one of chicklet key PETs. I'm very glad I didn't start by using C# or Java and never dropping down. The Mega65 isn't that different to the CX16, the documentation isn't very clear is half the problem. In some ways it's simpler, because you can write to screen memory in the same way you do on a C64/PET/VIC. In some ways it's more complex - DMA and stuff. Pricewise .... I suspect more M65 than SpecNext levels.
×
×
  • Create New...

Important Information

Please review our Terms of Use