Jump to content

kevtris

Members
  • Posts

    1,010
  • Joined

  • Last visited

  • Days Won

    24

kevtris last won the day on October 20 2022

kevtris had the most liked content!

Contact / Social Media

Profile Information

  • Custom Status
    FPGA Whisperer
  • Gender
    Male
  • Location
    Flyover, USA

Recent Profile Visitors

81,182 profile views

kevtris's Achievements

Stargunner

Stargunner (7/9)

4.3k

Reputation

  1. I was unaware that some cartridges might take awhile to become ready, so I just test once. it's been changed to test for 2 seconds, and show the error screen, but it will keep rescanning continuously and will boot if the cartridge ever becomes ready eventually. the fix will go out with the next update.
  2. ask and ye shall receive. here's my exchange with tommy. (tommy's reply, cut off my post he quoted) (video links removed) (removed where tommy quoted my entire post) since that, several more products have been released, while amico languishes.
  3. they would need to probably start ordering parts today if they hope to have it all. then figure start assembling in august at the very very latest. so they got some time to debug it, but they'd have to hire another engineer probably to redo the design; guessing lots of parts are EOL/not available/long lead times so they will need to do some major redorkulating. also, the extremely poor battery life and constant disconnections need to be addressed. the former probably is not fixable without hardware changes (bigger battery, etc) and the latter SHOULD be fixable with software, but that'd require debugging and someone to do that work. I'd be surprised if the controller gets made at this point. yes, those will need separate tests. they will need a total of four tests I think: safety test (battery, charger), emission test for bluetooth (intentional radiator), emission test for wifi (intentional radiator), and general EMI/RFI emissions (unintentional radiator).
  4. pretty sure it'd need safety testing since it has a lithium ion cell in it.
  5. yeah the only real way to ID games would be to CRC the upper 8K or so but even that isn't bulletproof- many mappers can start up in any bank so that means you'd have to store a CRC for every possible bank. though, for this application it isn't quite that bad- it only has to identify a fixed set of games and not the entire library. still it doesn't help the flash cart situation. it would be possible to have some kind of register that can be written to enable the required expansions, but that'd require flash cart devs to add that to their code. I actually do have that feature in there- the NSF player hack I did for the powerpak uses it, and automagically turns the correct expansion chips on for you.
  6. that wasn't a bug, it was conscious design decision. the reason is someone will turn one of those on, forget about it then wonder why there's weird noises coming out of their tv. so the solution is to make them reset when the power is cycled. there isn't a super good solution to the problem, and that was the one I came up with. (playing non-expansion sound games with one or more expansions turned on can cause the expansions to still make sound anyways, when the games write to their mapper chips which tend to mapped into similar areas. the best solution would be to somehow ID/fingerprint the game first and automatically turn the correct ones on, but that won't work for flash carts since their menus run first and would defeat any kind of identification. also I was totally out of space in the FPGA. it's a bit over 95% full right now)
  7. I know one thing. I would've liked to have been a fly on the wall when mike saw the super nt come out. The first real live FPGA SNES that didn't need a SNES jr. stuffed into a jaguar shell.
  8. The Analogue products would've happened anyways; I had FPGA cores done long before the chameleon was a thing. I find it hilarious still that mike wasn't really thinking much about FPGA until I mentioned it on a skype call, then everything I talked about all of a sudden became features of the retroVGS (which is what it was called at the time). I was showing off my Zimba 3000 idea and he glommed onto it. After the first call (I believe there were only two total, maybe three?) I knew that it was dead in the water and I never wasted any time working on anything for them, especially since there was going to be no money in it. He tried real hard to get my hyped up about it but I wasn't biting. It sure was a lot of fun though trying to identify everything they posted though. my favorite was the cardboard PCB with the parts glued down to it I think.
  9. not to mention a lot of it was semi-custom, teal seats and stuff on the chairs (OMG gotta colour-coordinate everything so the chairs match the walls!) selling used office equipment in a down market where everyone is working at home is one thing; selling teal office furniture is quite another; black/grey/white would sell much easier since it would go with a lot of things. teal just goes with teal and maybe orange but no one's going to have that kind of thing except tommy. Also when selling at an auction, you take what you can get if you truly want to unload it. it was definitely a buyer's market there.
  10. unfortunately since it's been so long, they would have to retool the design quite a bit now I think. it's been 5 years since the initial design, and so a lot of parts are most likely no longer available. There are most likely replacements available, but it means redoing some of the PCB work and that means engineering costs. Let's say they can get every part, and there's zero changes. It's going to be pretty expensive to manufacture just a few units. the cost to make 1000 vs. 100 is probably marginally more, since economies of scale start to kick in pretty good at the 1000-10K piece level (electronic parts). After that, there isn't much between 10K and 100K and even less between 100K and 1M. Be that as it may, the system itself is pretty expensive to manufacture, since they basically need to make three things. (two controllers, 1 base unit). I am guessing their total cost is in somewhere in the $150-200 range without including profit or shipping. This is manufacturing in china, and not in the US (where the total cost would probably be 3-5x this). Going by how popular (or unpopular as the case may be) for the games they have already released, there's no way they can sell more than a hundred or two systems at the rate they wanted, north of $300. Only 1 or 2 of the games have 100+ downloads, the others are stuck at 50+ or less. No one's going to bankroll a loser like this when the games are basically unsellable. So if they want to make 1000 units at $150 each, they will need $150000 to do it, which they more than that. They definitely had PLENTY of money to manufacture a run of 10K units (say, $2M) but tommy and friends just pissed it away on a non-stop office party and schmoozing around.
  11. The ROW and COL pins going to suzy follow the RAS and CAS pins (respectively) going to the DRAM most of the time. The two diverge when the address spaces of the RAM and peripheral/ROM overlap, though. When suzy is enabled, CAS and RAS are shut off in its address space, and when suzy is disabled, ROW and COL are shut off. Also, when suzy is DMAing it steals the DRAM bus from the CPU and has full direct access to all 64K of it (and no access to any register or ROM, because it's literally just banging on the DRAM). A B C D E clk _-_-_-_-_- _-_-_-_- _-_-_-_- _-_-_-_-_- _-_-_-_-_- cas -----__--- ---__--- ---__--- -------__- -----__--- ras ---_______ ________ _______- ---______- ---______- we ---------- -------- -------- __________ ---------- col -----__--- ---__--- ---__--- -------__- -----__--- rol ---_______ ________ _______- ---______- ---______- A - memory read, 5 cycle (start) B - memory read, 4 cycle (continuation) C - memory read, 4 cycle (end) D - memory write, 5 cycle E - memory read, 5 cycle (standalone) A B C clk _-_-_-_-_- _-_-_-_-_- _-_-_-_-_-_-_-_-_- cas ---------- ---------- ------------------ ras ---------- ---------- ------------------ we __________ ---------- ------------------ col -----__--- -----__--- -----__----------- rol ---______- ---______- ---______________- | extra cycles go here A - CPU register write B - CPU register read C - CPU register read, with busy (this one took 9 cycles) CPU timer register read/write can take up to 20 cycles to complete, in 1 cycle increments depending on where the timer is relative to the CPU A B clk _-_-_-_- _-_-_-_-_-_-_-_-_-_- cas -----__- -----__--__--__--__- ras ---____- ---________________- we -------- -------------------- col -------- -------------------- rol ---____- ---________________- A - refresh (4 cycles) B - DMA (this is just the DMA part. the entire thing is DMA, refresh, DMA, refresh taking 28 cycles) Here's some of the basic waveforms you can expect to see. clocks are the full clock rate. A "clock" is the 16MHz system clock. The address bus outputs the row, 1 clock or so before row/ras goes low, then it outputs the column between where row/ras went low and col/cas go low. Sometimes wait states happen, so I showed that. Sometimes the CPU will read multiple bytes in a row to speed things up a little, which is what trace A/B/C is about in the first set. For writes, data is output to the bus when WE is low. otherwise the bus is tristated and the RAM can drive it. Suzy fully monitors COL, ROW, and WE to know what registers to read/write. Remember that suzy will attempt to use RAS, CAS, and WE (and address/data of course) to access the DRAM directly when it wants to DMA. One fun suzy fact- it only has 48 registers. The main sprite registers and the math registers are exactly the same physical registers in the chip- they are not separate. So this means sprite rendering will affect what data is living in those regs if they are not reloaded before math is attempted. This means register fc00 is the same as fc40, fc01 is the same as fc41, and so on. Registers fc30-3f and fc70-7f do not exist and will return suzy open bus if read. Of course you still need to write to the math range to make the math work properly (i.e. for signed multiplies so it can doctor up the words and make them positive) and to start a multiply or divide. But you can do fun things like write a positive value to one multiply register, then poke a negative value through the sprite area and start a multiply to see what happens. (spoiler: it treats the negative number as positive). eta: the "refresh, DMA" part is from the CPU and not suzy's DMA btw. This is for reading the frame buffer to display on the LCD.
  12. generally not on these kinds of radio since they application specific. There are filters you can buy and install in line with the antenna to filter the spurs and harmonics out and this is a decent way to go.
  13. neat. you can get rid of spurs on the RF output by tweaking some software? first I heard about that. generally you need filters or an antenna redo to fix that.
  14. yes, that would be me. I have dumped 50-60 or more hand held game CPUs and took pictures of the guts and vectored many VFDs. to the thread author, the code is a disassembly of the dumped binary from the game. The source code is not freeware and is still technically copyright by whoever wrote it. The CPUs used are generally somewhat obscure 4 bit ones, and the best source to understanding them is probably the mame source code (mame runs most of the dumps I have made, so if you really want to play the coleco tabletop games you can do that through mame (or many many others)). The chip datasheets are available but don't list the opcodes for each instruction, which is where the mame source comes in. I dumped these by reverse engineering the chip and figuring out the factory test modes to dump several different kinds and brands of microcontroller used in these. Then some custom hardware was made to do the job.
  15. this isn't true. my 68K is based on the decap, and I used extensive logic analyzer and chip testing to reproduce functionality of the rest of the system. my 2600 and 7800 cores are based on the chip schematics.
×
×
  • Create New...