Jump to content

sage

Members
  • Content Count

    1,269
  • Joined

  • Last visited

Posts posted by sage


  1. Hi there,

     

    Maybe a few of you wondered why there is (in the original BLL kit) a com program to interface the lynx with 31250baud to an Atari ST?

    Short answere: The Lynx has some very weird baud rate setttings. The onyl useable for a normal PC is 9600baud, but 31250 matches exactly the MIDI specifications. And the Atari ST comes with a MIDI port.

    Makes debuggin and uploading much much faster.

     

    BUT (now comes the bad things):

     

    1. MIDI is using a current loop (5V) while comlynx is level sensitive to 5V. Thus you risk either to damage something or you need some adapter. Nothign special, a simple optocoupler and a few resistors & diodes. Actually, the MIDI specs require that you decouple the MIDI In. PS: Did I mention that, if you "just" connect it by some passive resistors, the polarity of the signal is inverted?
    2. And, you need to set the serial setting to 31250E1, because the lynx expects ALWAYS a parity bit. Very bad, because the MIDI specs are 31250N1. This can be done easily if you have a ST or PC where you can set the port parameters. You just have to remember to do it.

     

    Q: Now, if I build me some adapter, could we use MIDI In to connect a Keyboard to comlynx?

    A: No. (Reason 2). The Keyboard will send out data withou parity bit. The Lynx will reject the data bytes (even if you disable parity checking!).

    A: Yes. If you but some "intelligence" inbetween. A simple microcontroller will do. Or a Laptop.

     

    So, You connect the keyboard with a midi adapter to your laptop and use an configurable(!) second adapter to send it out including parity. Or, to make it a bit simpler, you send out the data by a normal serial port with 9600E1 setting, which interfaces directly with a standard serial-comlynx interface.

     

    9600 is a bit slow for MIDI, thus the timing is a bit ... inaccurate. But: Its working!

     

     

    • Like 1

  2. technical details:

    Cast of char array to long (32bit) and bit masking for for string case-insensitive comparison.

    Comes close to self-modifying code ;-)

    I really wondering now that it worked at x86 architecture / newer processors at all.


  3. Hi there,

     

    you can find a new bugfixed version of lyxass on my website, lyxass v49.

     

    Fixes:

    * 64 bit and architecture problematic code has been replaced

    * some strange things about the parser have been (hopefully) fixed

    * few includes have been changed

     

    -> works now with 64 bit gcc and clang

     

    please report if you find more issues

     

    • Like 4

  4. Lynx music really seems to be an area ripe for development. None of the released games, aside from Klax, use music and sfx as an integral part of gameplay and show off MIKEY to its full extent. The music and sfx in Loopz is fabulous, but I cant think of another game that approaches those two...perhaps Toki? Raiden would have been 10x better with in-game music.

    Sorry, but playing samples (or mods) does not "show off" anything. Its just boring. The asic is designed for that. you stress memory and cpu (which is no problem in KLAX).

    Proper chip music is much much harder.

    • Like 1

  5. Thats maybe not the way the collision buffer should be used. But yes you can initialize with other numbers. but why would you want to?

    Any sprite will fill the collition buffer with its "collision number", if the sprite has correct type and collision is on.

    Transparent pixel <!=> uncollidable pixel -> read the docs.


  6. yes I checked quiet some games for Stereo wen doing the stereo and attenuation sound patch for handy core. But I guess I lost it.

    Was quiet easy to check, as I just had to look for each rom in the emulator if the register(s) were accessed.

    • Like 1

  7. ... actually you can find the latest code on github.

    I tried to sync the core between handy, sdlhandy and retroarch (mednafen is skipped because of its unwilligness of accepting patches).

    Thanks to LX I could compile handy with VS16, but this version is more beta because the boot replacement is not user-friendly switchable. EEPROM support is only partly available.

    • Like 1

  8. exactly. follow the schematics on BLL site or of maxim directly. buy cheap rs232-usb. together about 1000yen.

    (maybe you can even get rid of the rs232 voltage converter as you can even buy USB serial with different voltage levels.

    http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm

     

    but I have the feeling that the purpose of the question was about comlynx between games. answer: no.

    reason: there the main problem is that from PC side unusual RS232 frequencies are not supported, even if the adapter might support it.

    nothing what is unsolaveable, but at least you need to fiddle a bit with microcontrollers.


  9. Seems quiet some time since I released the last updates... but now here they are:

     

    Version bump to 1.9.1

     

    * better on ignoring empty (or close to empty) lines

    * A few changes to the "default" behaviour

    * a few extra checks that reduces the chances for stupid mistakes in .mak files, return error code (for Makefile processing)

    ** checks that at least one loader type is defined or NOLOADER is given explicitly

    * automatically sets the block size and dirstart to the selected loader (if applicable), still they can be overwritten if needed

    * support empty entries

    * create several (n) empty entries (nice for hacking)

    * improved banking support (AUDIN and BANK2)

    * updates manual

    * eeprom type bits for emulation

    * ... and some more things I forgot

     

    get it at the usual place

×
×
  • Create New...