Jump to content

cathrynm

Members
  • Content Count

    73
  • Joined

  • Last visited

Posts posted by cathrynm


  1. On 8/28/2021 at 9:33 AM, tschak909 said:

    I tried to apply for anything at VPRI just to get around him, was summarily ignored. oh well.

     

    -Thom

    I was turned down both by Atari and Intellivision in 1982, when I just graduated BSEE. I think I screwed up the interview, which I tend to do with jobs I actually want..

    • Like 3

  2. On 10/23/2021 at 9:25 AM, flashjazzcat said:

    I think all A8's are technically 'out of spec' in one way or another, but an issue which (in my experience) requires a 'fix' on the base machine more than fifty per cent of the time cannot really be retrospectively blamed on the quirks of the target platform. I say this as someone who would have no idea where to begin designing hardware or writing VHDL, BTW.

     

     

    I've been poking around the Mister Atari 8bit core, basic since I kind of still know the hardware, and I'm curious about FPGA. It's mostly VHDL.  I'm just tweaking easy things for now, making simple changes. There's some of this that is just sequential, like programming, really, and obviously there are bits that are not. Main thing that's a hassle is that the compile times are pretty brutal. I have medium-new PC here, 8 cores, and it still takes 10s of minutes to build.  Right now, just dealing with syntax issues.  I still keep typing '==' instead of '=' and '=' instead of '<='.

    • Like 2

  3. Well, I don't know about you guys, but I voted for LightGun to PS2 mouse interface.  Not even sure what this is, but I like to see started projects get finalized, and looking forwards to some Bug Hunt, maybe even on an HDMI monitor?

    • Like 1

  4. Does anyone make a dongle for using USB gamepads on Atari 8-bit, 2600s, C64, etc. I try searching for this, but I get too many results for the reverse, for using 9-pin joysticks on modern PCs/emulators. I can't figure out how to do the other way around. Am I missing something obvious here?


  5. On 10/12/2020 at 5:18 PM, Guy1 said:

    It was advertised. It plays well. And it's rated fairly highly on AtariMania...

     

    And yet it is listed as a Prototype... Did Inhome Software go bankrupt or something?

     

    How and when did the prototype surface?

    Don't know the story or timing on this one, but the bottom dropped out of the Atari 8bit games market pretty suddenly. Wouldn't surprised if some games got dropped, just because there wasn't a market anymore.


  6. 22 hours ago, PixelCrunch said:

    4: Why isn't anyone making more use of it?!

    Oh I know the answer to this.  Because making a game, any game, is a lot of work, and the audience for this is small. That said, if the Incognito Atari 800 adapter gets released, I'll consider getting one for 80 column with Spartados.  I did peek at the docs. I think 2d games are possible with the blitter. You store all your art in VBXE memory, and then draw the entire screen with the blitter. Maybe fake 3d games are possible? Not sure if anyone has made any fake 3d demos with VBXE. I don't have one, so I don't pay much attention, tbh.


  7. 4 hours ago, Mazzspeed said:

    So this device has the ability to auto switch between 40 and 80 columns depending on source used?

     

    Did the original XEP do that?

    Nope.  XEP has a seaparate connector on the back, hooks to an 80 column screen only.


    This looks like a nice feature. Fussing with two monitors or switching monitors just for XEP80 is awkward.

    • Like 1
    • Thanks 2

  8. 1 minute ago, tschak909 said:

    The ram that the N: and R: use, comes from the PSRAM (upper RAM, of which we have 4 megabytes currently mapped, and we can bank switch another 4 megabytes when needed), and we tried to go out of our way to make sure that malloc() and friends allocate from PSRAM first (sdk config). This is separate RAM from the 320k that's on the ESP32, and is connected via the SPI).

     

    -Thom

    I see, yeah, sounds like this is already optimized. I'm still stuck on the 'two versions' idea, I'm afraid. Would it be possible to build an SIO2BT version with the old tools, and the main version with the new tools? If so, then at least you could get unstick for now, and though the SIO2BT would be stuck on the old tools until you ripped out enough stuff to make it function,SIO2BT wouldn't be totally orphaned -- maybe it becomes a pain to build.  The main version could continue developing on new tools as before.

    • Like 1

  9. 33 minutes ago, mozzwald said:

    Firmware is one big blob. I'm not really sure how or who uses SIO2BT mode. We could make two versions of the firmware, but if this idea works and can keep the functionality of both in 1 firmware it would be better.

    It sounds like the effort of this is to figure out what exactly can skip initialization if SIO2BT is still around, and then hard to know if that's enough to save SIO2BT. N:, R: do they really use that much RAM? I wouldn't think they need such big buffers, maybe something I don't know about here.


  10. 3 minutes ago, mozzwald said:

    In SIO2BT mode, the Fujinet is just a passthru device. The android app sends all the disk data over and Fujinet is effectively a disk drive only. So, all the other code for N, R, etc can be left uninitialized saving RAM.

    I see. Does the platform support DLLs or overlays or anything like this?  Or is it just compiled as one big blob?  Would it make sense to build two versions, an SIO2BT version and a regular version, with a bunch of #ifdef separating one from the other?   I've never used SIO2BT mode myself, do people who use this tend to switch back and forth?


  11. On 8/3/2021 at 9:30 AM, mozzwald said:

    One of the big problems with memory usage is Bluetooth functionality which uses a HUGE amount. The newer esp-idf toolchains won't even build the current firmware due to the ram use. We have been discussing removing bluetooth support for the time being.

     

    I had an idea that may or may not work by disabling BT at boot but you can turn on BT mode which would force a reboot into BT only mode. Another reset would return FujiNet to normal/wifi mode with disabled BT. This is the function that disables the BT stack:

     

    https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/bluetooth/controller_vhci.html#_CPPv229esp_bt_controller_mem_release13esp_bt_mode_t

    Trying to understand here. That would  fix it for no Bluetooth, but then what do you sacrifice when Bluetooth is active? Would there be any obvious 'memory cows' around to shut down to have enough RAM in this case?
     


  12. On 7/25/2021 at 12:05 PM, tschak909 said:

    I am currently running the #FujiNet firmware through the PlatformIO inspector, and have noticed we're overflowing a bit on RAM usage. I'm currently investigating, and if anyone wants to jump in and try to whiddle it down with me, have at it!

     

    image.thumb.png.ab338a214d67102696b434e3dddfb0cd.png

     

    The code is, of course, here: https://github.com/FujiNetWIFI/fujinet-platformio

    This kind of thing, memory usage, also performance and random bugs, is actually more difficult to work on than adding new features -- unless there's some kind of 'big stupid' to find, but that's luck, a large part.

    • Like 1

  13. I'm trying to get a MIDI XEL II working with my Atari800, just bought from brewing academy.  I just wire the SIO cable to the same labeled pins, right?  Or does anything have to go between the Atari Data IN and the DI connector on the device? It can float, right, for when other stuff is using the bus?  I thought I hooked it up correctly, but it's stopping anything else on my SIO bus from working when I do. Going to check once again to make sure everything is right. I do see the LED go on with the motor command, so at least I didn't wire it backwards.

×
×
  • Create New...