Jump to content

BruceMcF

Members
  • Content Count

    880
  • Joined

  • Last visited

  • Days Won

    24

Everything posted by BruceMcF

  1. On the, "if it's for industrial control, why is it so clean?" front, it could be for Point of Sale, so the computer part can be secured in a padlocked enclosure so your low wage tellers don't sneak the C64 home to play games on.
  2. I keep hearing about feature creep, but I rarely hear about what features were supposed to have crept. The most recent change in the Vera reduced the bottleneck of the two data ports while cutting, not adding, a feature. That was a feature replacing the 65xx family serial interface chip, which was in turn replaced by a decision to bit bang the serial on the User port. That is, if anything, the opposite of feature creep ... feature pruning. Maybe because the design team has a wise policy of not discussing some features at the "we'd like it but it's not clear if it's feasible" stage, and then when it's described some people imagine it the feature had never been on any internal feature target list? There is already an SPI interface, for the SD card, and an SPI interface can be bussed. There are SPI to GPIO chips, SPI to serial chips, SPI to I2C bus master chips, SPI serial RAM chips, etc., so reusing the existing SPI bus seems like the likeliest to fit if the X8 doesn't have many unused logic resources to spare.
  3. Yes, they are manufacturing a bubble, attracting new money in by engaging in self dealing to make it look like there is growth in collectible value, so money is attracted in by the growth in the market, and continuing to pump up the market with self dealing to reinforce the idea of the outside money that they are profiting on their collecting. Ad long as the game continues to attract new outside money, they'll keep playing, then when the "new money" dries up, they'll dump what they were self dealing before and prices will crash back down as people decide it's time to "cash out". It's a zero sum game, so all of the insider's net gains in the process are somebody else's net losses. Note that some of the insider gains will be transaction fees. When you are paying $100,000 for something, a 1% brokerage fee seems minor ... but if it is something that would cost $5,000 in a market that was not being pumped up, that is magically pushing a 1% brokerage fee from $50 to $1,000. That extra $950 never shows up in the "value" of the collectible but it's also money in the bank account of the insiders creating the bubble.
  4. Yeah, and it's massively tangly spaghetti code. My Swift16 65c02 uses a faster JMP (a,X) execution loop and no spaghetti code it's around 3 pages. I am pretty sure it can be ported to the X8 VRAM bank. https://github.com/BruceMcF/Sweeter16
  5. Just need the last six bytes of each page to be "STY VRBANK : JMP ($0400,X) and to call to a " far page", LDY #hibyte : LDX #lobyte : JMP $04FA
  6. That last wouldn't seem the most direct approach, since the boot up seems to be two pages at $FE00-$FFFF, so it seems likely it just reads a chunk of data from the serial flashRAM and writes it straight to where it goes. There might be a write protect bit, but it seems more likely that Basic just happens to be the default code sitting in RAM that happens to lie below the Kernel and if you don't need Basic, you can just take over all of the space it normally uses. Except for routines writing to VRam, the obvious places to put little widget routines is in VRam, so it can be executed by switching $0400 to the page holding the widget routine and executing it. Which, similar to the use of VRam for data buffers, would discourage heavy use of higher color depth and resolution bitmap modes. IF it was possible to make an IO hat for it, it could be a fun little board, but it would be very much its own thing when programmed in Assembly.
  7. See the general chat thread at: That also explains more clearly what I mean by "from unofficial sources". This is tentative until/unless there is a specification from official sources, but it makes sense based on the simplest way to give access to the part of the internal FPGA RAM dedicated to the Vera functions.
  8. It's almost certainly economies of scale. When you subtract the kits bought by people who don't want cases, the number of large cases can easily be less than 1000. Indeed, if you don't have cases, but have "support" tiers that include keyboards and some different goodies (name on a supporters page, printed docs, etc), it's a lot easier to put together a crowdfund campaign that can be structured to break even on keyboards than to structure one that can break even on cases. You might even want to set the "go" volume on kits at 200 and cap the first campaign under 500 X16p kits, to make sure you avoid "fulfillment hell" and the bad reputation it brings. If the crowdfund is a runaway success, then there should be financial flexibility to just produce more kits and sell them on pre order in batches. And if it funds but doesn't max out, you know where to set expectations on the market. If there is also an X8 with keyboard tier in addition to keyboard support tiers and a range of 200-500 kits in the first campaign, hitting break even on keyboards would be pretty straightforward, while hitting break even with the Micro-ATX cases could easily be infeasible.
  9. Yes. From the FPGA people have worked from pictures of Vera, there is a 128KB RAM module built into that FPGA. It is single ported ram, so only one FPGA circuit can write it or read it at a time. The fact that it is built in is how Vera can have an internal VGA dot clock of 50MHz. The X16 uses all of that as "VRAM". The X8 reallocates 64KB for the 65C02 " soft core" to use. From unofficial information about the X8, the page in the X8 CPU system address at $0400 is always the page of VRAM set by the VRAM bank register. The page at $0500 always maps to a fixed set of Vera registers. The I/O that takes part of page $0700 always accesses the control and data registers for that I/O. The VRAM window "moves around" in VRAM, but its location in the CPU memory map is fixed.
  10. I think there are specific types of situations where "provide a link" might be ambiguous whether the link is in the source or, somehow, in the program itself. With a command line utility, that is easy enough by giving a -by command line switch, but with a device driver or similar, it might be tricky. The dedicated programming open source licenses are explicit about where any attribution goes.
  11. (1) Why would it be? Both are different locations of the same RAM module. That's why the VRAM is half as much ... not because it's a smaller RAM module, but because half of it is being used as system RAM. (2) And if it was, how would you know, since you can only read VRAM at $0400. You cannot read "CPU RAM" there. So if for some reason it was designed to write the byte to the half of RAM treated as VRAM location and THEN in a second step to write the byte to the half of RAM treated as CPU RAM, you couldn't read it back from the CPU RAM location. The thing is, it doesn't mean any FEWER X16 systems released until the "third phase", which was always described as something that needed the first two phases to succeed before being released. I think the fact that the X16p is the one running almost entirely on new ASIC chips on a big motherboard people solder by hand and the X8 is an all-in-one FPGA device makes for the strongest distinction you could hope to achieve. Which is why I argue it's probably OK if the X8 and the X16p DIY are released side by side, because they are hard to confuse with each other. Then if the X16p has been released, the X16c is self explanatory. It does mean that the X16e doesn't make much sense unless BOTH the X16p/c and X8 are successful, so that you bump up to the FPGA that is large enough to allow the FPGA + 2MB RAM chip approach to work, and has enough additional logic to support an OPM+DAC core, and then you provide a setting in what is otherwise empty I/O slot space, which sets an X8 compatibility mode.
  12. Because the X8 does one page to write to the 64K video RAM, one page set to a dedicated page of Vera registers, and some dedicated I/O. If you wanted to be "plug and play" run X8 software, eight bits doesn't cover it. Since the X8 page "window" is locked at $0400 in the current X8 memory map, and it it always VRAM read in that page, it doesn't matter whether the "system" RAM at $0400 is written, but it likely isn't, since it's the same 1Mbit of singleported RAM organized as 128KB. So a redundant write to the "actual" $0400 would require more FPGA cycles.
  13. IBM selling its PC division to get out of the PC business is exactly what I was referring to ... Yes, I was sloppy in saying computer maker when I should have said PC maker. Indeed, to the extent that Power System servers are the descendant of IBM mainframes and minicomputers, they were in that part of the computer business long before they entered the PC market, and with "cloud computing" there is no particular end in sight.
  14. The thing about the the page window is in the 6502, if you are writing to an arbitrary RAM location, STA (W),Y is replaced by STA $0400,Y ... and when you adjust the high address of the address by adjusting the high address of the zero page location in a normal RAM access, with a page window, you do the same adjustment to the page window register ... ... instead of INC W+1 you do INC VRPAGE ... ... so you can implement line drawing routines as fast in the X8 system as in a direct RAM based video display. Implementing the X16 access STYLE in the X8 may or may not be possible, but it wouldn't be at $9Fxx ... to be plug and play compatible, it would be a shift of the X16 IO page to $0400 and shuffling the X8 IO pages around so the unique IO register at presently $0600 and up are where expansion slot locations are in the X16 IO page. Also, it might not be possible in the Vera FPGA ... the logic resources used to implement the auto incrementing data port registers might be used for something else by the X8 ... the X8 has an entire extra 65c02 core implemented that Vera doesn't have. To be compatible with reassembly or patching to a different IO location, the Vera 32 address slots could be implemented in the X8 somewhere in the general IO registers presently at $0600 and up. But it might require stepping up to the next larger FPGA in the family. Implementing X8 style access for the X16 requires the same moving the IO page down to $04xx, with VRAM window in $0500 and Vera register page at $0600 ... but also a bigger FPGA to give it the IO pins to have a two select lines (for IO slot select and X8 page select) and 9 address lines. And a complete shuffle of the chip select circuits.
  15. Thing is, it might not be possible. The logic resources to do the the two independent autoincrements on the two data ports are freed up by the X8 approach ... it's just an internal latch generating the effective high eight bits of the "video" RAM address ... and those logic resources might be used by the ADC/SBC/CMP operations and the ,X and ,Y address modes. For the X16e, it wouldn't be nerfing: the design would be to simulate the X16p, and if you need a bigger FPGA to do so, you just switch to a bigger FPGA than Vera uses, in the same family. You have to switch to a bigger FPGA anyway to get the 14+1 or 22 address bus lines and 8 external data bus lines ("+1" if it multiplexes the high address bus lines and the data bus, using a toggle line rather than chasing the Phi Clock like the 65816). But since the X16e isn't supposed to have slots, it has plenty of room to put a toggle bit to switch to X8 addressing the first 64KB of video RAM and more of the Vera internal registers in the X16 Golden Ram, so the X16e could well be designed to be compatible with both, which would kind of justify being twice the price of the X8. Indeed, that'd be the design that could be considered for a third campaign, if the sales of the X16p/X16c and X8 indicate there might be an appetite for such a beast. _____________ Sure, if you want to do a vector game in what was originally a sprite and tile video system, and don't require a lot of game resources ... the extension RAM can also allow preloading a lot more things from the SD card as a level is playing, so it can do things faster than putting up a load screen and loading from the SD card when you need the assets. I expect vector gaming on the X# family is going to be like when David Lettermen's Stupid Pet Tricks had a cat that would actually do a trick come on ... people were not impressed by the trick itself as much as by the fact someone was able to get a cat to do a trick. Sprite and tile games are going to be more of the bread and butter.
  16. To be fair, only one of those three exist as a computer maker, and for that company, making computers sometimes seems like it is more of a sideline to making smartphones. Edit: Oops! "PC maker"
  17. Yes. The thing is, if the X16c would fund, at the minimum volume required for the customization of the Mini-ITX case or the Keyboard (whichever is higher), a normal mark-up will cover most development costs, and the sunk cost into the keyboards will be automatically recouped. That is the challenge with the phase 1, phase 2, phase 3 process ... it had the pyramid upside down, with the lowest volume, highest price phase trying to kickstart the middle volume, middle price phase, which in turn is trying to kickstart the potentially highest volume, lowest price phase. The way that the X8 + X16p DIY crowdfund launch would work would be by setting a funding target that can recoup the sunk cost in the keyboards. Something like the following: Support Tier: $10. A customized pdf of the docs with a signed thank you letter personalized to you, and unless you select anonymity your name in the supporter list in the prelude section of the docs, X16 and X8 emulators of your choice of system (Windows, MAC, the two largest Linux distros) and a year email notification of updates to the emulator/documentation. Emulation Station Tier: $10+ project pre-order price of kbd. The above and the multi-mode PS2/USB project keyboard. Premier Emulation Station Tier: Emulation Station tier plus printed X8 and X16 documentation, USB key with X16 project branding, install files for emulators plus install files for portable installations on the USB key X8 bare board: Pre-order price of bare X8 board, drop-in SD card with included and demo programs & utilities. X8 kit: Above and power supply, keyboard, printed X8 documentation X16p DIY: Minimum 200, Maximum (a reasonable cap on kits that can be fulfilled), + keyboard + printed X16 documentation And be sure to budget the crowdfund target so that the cost of the keyboard minimum order is covered, which necessarily recoups the 50% deposit. Pre-order Price the keyboard so that at 80% of the minimum order the purchase price plus a reasonable handling cost is covered. So the first crowdfund bails out most of the buckets of red ink from the bilge of the Great Ship Project X16. Now, if the first wave funds, there is going to be pent up demand for built systems. The X16p design was always much riskier than the X16c one, so while fulfilling the first campaign (never have the fulfillment and launch of the next campaign overlap) finalize the X16c design, and put together a new campaign. Same three support tiers X16c system, with keyboard and case, budget the minimum required based on minimum order required for case customization tweeks and minimum keyboard order. X16p built boards + keyboard, with a narrow range between the budgeted required support for the tier to and the maximum order allowed. Add up the X16c and X16p minimum budgets for the project to fund. If the second campaign funds, the project is now in the black, including opportunity costs. If the second campaign fails to fund, look at which tier let you down and see if you can restructure.
  18. Yes, that is one of the principle differences between pre-orders and crowdfunding ... with a crowdfunding campaign, you set a minimum volume required to breakeven at the crowdfund price, and that minimum volume determines the crowdfunding target required to launch.
  19. Though in a japanese style visual novel, if the bottom third of the screen is reserved for text ... now 320x160 ... and most in scene changes happen in a foreground while the scene background is stable ... so in scene changes are in the upper bitmap layer in a 160x120 section centered in the 320x160 lower bitmap ... preloading from the SD card into three High RAM banks while the player is reading and loading to Vera from HiRAM would make in-scene transitions pretty snappy.
  20. The point there is not general purpose toggling between banked routines but minimizing the overhead in doing so for the cases when you know it's from one specific one to one specific one. So in this case ... something that fits within 8KB would not use it, of course! But you can still hold onto that 2.5KB spare space in case one of the other units (interpreter or compiler) is bound by the 8KB bound of a single bank and splitting out one or two longer subroutines, or a distinct submodule that is not in a tight inner loop (eg, an initialization module) to a side bank helps it fit comfortably.
  21. Yeah, but that's only going to be a small part of the user base for a system with millions sold. If the Z80 has been dropped in favor of the 65816, then it would need a new name, as it would no longer be CP/M Plus compatible. If it had 256KB base RAM and 64KB 80 column video RAM, it could be the Commodore 256. Or the Commodore 320. That would also make the geoRAM access of the extra RAM in legacy 6510/C64 mode 192KB, rather than a mere 64KB, so, eg, able to hold a 1541 disk's worth of data. It would be an even bigger selling point if as you mentioned the "C256" allowed the easy addition of extra internal memory modules, and those also could be accessed geoRAM style in C64 mode, so that someone with two 256KB internal RAM expansion modules would have the equivalent of a geoRAM 704KB expansion. There would have been a possibility of a virtuous loop of C64 programs taking advantage of geoRAM memory expansion, which would then help sell both more geoRAM cartridges and more C256 systems, which would increase the install base to run C64 programs that could take advantage of geoRAM. And the 65816 replacing the z80 with direct banked access to the extended RAM would have been a shorter learning curve for 6502 programmers used to programming for the C64 ... but then again, Jack Tramiel would never have gone for a CPU that he had to pay a license fee on for every unit sold. As he said, he got married once, he didn't intend to repeat that in the computer business. But I've seen the time travel movies ... if someone goes back and Ghost of Christmas Future's Commodore into phasing out the C128 in favor of the C256, and pushing the cheaper geoRAM memory expansions for the C64 over the more expensive (and more capable) REU's ... then that will change some detail of somebody's childhood in some way, and half of us disappear because of the nuclear war of 1998.
  22. Or fixed ... the Z80 part was a horrible kludge, with the clock driven by the 12V line and then capped at 5v because the edges of the 6502 clock were too soft on the rising cycle for the Z80 to work on the original 5v system PHI2. And AFAIU, rather than wait states, it just stole clock cycles from the z80 whenever the boarded wanted that phase of the clock, which is silly since over half of the time the Z80 is running an internal cycle and doesn't need to access the board. But the z80 is the start up processor, so it can decide whether to start up in C64 or C128 mode. If you could get an 8MHz frequency source, sharpen it into a proper z80 clock at 4MHz with a flip flop circuit, use that to generate the 2MHz and 1MHz clocks and generate a proper wait state system for Z80 access to RAM, and put it in a keyboard case with a built in 1581 or a C128D case with a built in 1571, you could have a unit you'd be able to sell a discount bundle of C128, second drive, monitor and CP/M productivity software with, as it would be price competitive and have similar performance with the 4MHz Kaypro's etc. at the time. Otherwise likely fewer than 5% of users ever actually the z80 for anything other than hitting or not hitting the Commodore key on power up. This is the key, though ... a C128+ would have a switch of some sort that made the extra 64K available as a GEORam, with a 256 byte window in the EXIO2 page and the address register in the EXIO1 page. With C128's running in C64 mode 80%+ of the time, being able to run as a BETTER C64 out of the box would have sold more units, which would have increased the C128 install base, which, in a twist, would have had a shot of improving the C128 ecosystem and giving people a reason to run them more often in C128 mode. A 65816 would be nice, but it would have to replace the Z80 as the start up processor, and when C64 mode was selected, start up the 6510, for C64 software that used the undocumented accidental opcodes of the 6510, and with the C128 operating in C64 a majority of the time, most people would not see the resulting benefits for most of their use.
  23. BruceMcF

    My X16 Case

    Hence the mandatory verbal warning, "I am opening this computer case. This is an old fashioned case made of rolled steel, so children should clear the room!" ... ... which acts as a magnet for children to come around and see if anything interesting is going to happen.
  24. An advantage of a tokenizer in Bank 1 is that if it outgrows the bank, you can either take "longwinded" routines and put them in Bank 2 or modularize and split modules between Bank 1 and Bank 2 ... Cross module call, dispatch vectors in $BFxx, CALLXB in $BFxx, Y free: ... : LDX #operation : JSR CALLXB ... ; Bank 1 version CALLXB: LDA #2 : STA $0000 : JSR + : LDA #2 : STA $0000 : RTS : + JMP ($BF00,X) ; Bank 2 version CALLXB: LDA #1 : STA $0000 : JSR + : LDA #1 : STA $0000 : RTS: + JMP ($BF00,X) The magic is, of course, that at "STA $000", you bounce to the other bank's version. That is a lot more overhead than a subroutine call, but less than a general purpose cross bank call, so it makes program units of either 8KB or 16KB and the distinct units can have the additional overhead of a more general purpose cross bank call.
  25. I might have missed that, likely from doing something else while it was playing. If someone recalls where that discussion happens, that would be informative. As with several aspects of the project, the idea to do the crowdfunding here at this site was pretty ambitious ... there are reasons why crowdfunding has coalesced on Kickstarter and Indigogo, rather than the bulk of it fracturing out as the market has grown. It doesn't seem like it could migrate to Vera, with I/O pins already constrained enough that adding two address pins made them cut the UART function out ... but in any event, it is clear from the thread on the topic that it is either going to be with the VIA or with the ATTiny, where the second solution would be in line with how the original PC-AT keyboards were accessed (which IIUC was then eventually followed by the clones all moving to Super-IO chipsets, but that all happened when I was no longer paying any attention to what was happening with PC hardware).
×
×
  • Create New...

Important Information

Please review our Terms of Use