Jump to content

desertfish

Members
  • Content Count

    387
  • Joined

  • Last visited

  • Days Won

    12

desertfish last won the day on March 3

desertfish had the most liked content!

Community Reputation

277 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Welcome and have fun. May I ask what part of the GDR? When I was little, we visited the city of Weimar and the surrounding area a few times with my family (we're from the Netherlands). That was in the 80's so it was still GDR.
  2. Can we have a moment to also appreciate the fantastic looking manual !?
  3. Version 1.0.0

    6 downloads

    Vertical "raster" bars, also known as "kefren bars" from the old school demo scene. Written in Prog8. No sprites used, it's bitmap graphics (with a trick...). Source is here https://github.com/irmen/prog8/blob/master/examples/cx16/kefrenbars.p8
  4. Vertical bars demoscene effect View File Vertical "raster" bars, also known as "kefren bars" from the old school demo scene. Written in Prog8. No sprites used, it's bitmap graphics (with a trick...). Source is here https://github.com/irmen/prog8/blob/master/examples/cx16/kefrenbars.p8 Submitter desertfish Submitted 03/03/21 Category Demos  
  5. I am using the assembled BIN file only, so no impact for me
  6. The current symbol table implementation is simplistic but should be easily replaceable with a different smarter one. Because it has a very basic interface to the assembler logic itself. I don't think I have the time to build a smarter symboltable myself, so hopefully someone else can jump in, who knows
  7. Yeah but I linked to a specific comment in that topic, which mentions GeckOS - a text based OS.
  8. No, not really... All good string hash functions use multiplications and we can't do that on the 6502 and also still keep it fast...
  9. That is an interesting idea. Sometimes "good enough" is good enough and we can think of a different symbol name to satisfy the assembler.
  10. Well, a correct hashtable implementation will deal with collisions (colision lists or other solution) Not dealing with possible collisions will result in extremely hard to track down bugs in your resulting machine code. Without any warning certain symbols suddenly will pick up the value of others... I can't imagine that's acceptable in forth either. I assume it uses a trick to deal with this as well
  11. There's this as well... so many unixes....
  12. I've fixed the issues in a new upload. Turned out it wasn't correctly handling absolute-indexed with symbols About the symbol table: how does Forth deal with collisions? prefix+length is way to simple ( "name1" and "name2" will be the same entry) and adding a "checksum" will only work to a certain extent if you mean "hash", I suppose. Still there is no guarantee that we don't have collisions.
  13. Prog8 6.2 was just released. As always the documentation is here and the git repository is here. Changes: - like the R0..R15 virtual registers, the carry status bit Pc does no longer have to be specified as the last parameter but you can put it anywhere. The compiler will sort it. - simplified the set_irq routines - added irq handling routines for the commander x16 - added commanderx16 rasterbars irq example - added cx16 vtui-library example, improved graphics on cx16 port of tehtriz and added sounds to it - added animal guessing game example - duplicate string literals are optimized better - slightly optimized the gfx2 module pixel position calculations - commanderX16 compiler target improvements - source code restructurings to reduce internal dependencies - bugfixes - documentation fixes
  14. Hi thanks for trying it out. Can you post the failing program? Because it should be able to deal with undefined symbols
×
×
  • Create New...

Important Information

Please review our Terms of Use