QR code generation

[iss]

Well, I just realized that in the description of the YT video is a link to the asm sources:
https://github.com/The8BitTheory/qr128

[Goodwell]

Absolutely feel free to check out the code at https://github.com/The8BitTheory/qr128
The asm subfolder is most interesting for you.
The branch mega65 is most up to date currently, I can update the main branch to make it more aligned.

Just wanted to let you know that I‘m happy to help if it makes sense.
But please feel free to have a look yourself

[Goodwell]

Well, I just realized that in the description of the YT video is a link to the asm sources:
https://github.com/The8BitTheory/qr128

Right

(My previous message was too late)

[iss]

Absolutely feel free to check out the code at https://github.com/The8BitTheory/qr128
The asm subfolder is most interesting for you.
The branch mega65 is most up to date currently, I can update the main branch to make it more aligned.

Just wanted to let you know that I‘m happy to help if it makes sense.
But please feel free to have a look yourself

Thanks! ( Danke sehr! )

[iss]

Absolutely feel free to check out the code at https://github.com/The8BitTheory/qr128
But please feel free to have a look yourself

THIS IS UNBELIEVABLE!!!
504 milliseconds!
Bare code size: ~1840 bytes!

Very well done @Goodwell.

I will share adapted to XA assembler sources and they should be usable for any other 8-bit platform.

[xahmol]

Super and very useful!
Will certainly use this.

[Goodwell]

Absolutely feel free to check out the code at https://github.com/The8BitTheory/qr128
But please feel free to have a look yourself

20250506_101850.jpg

THIS IS UNBELIEVABLE!!!
504 milliseconds!
Bare code size: ~1840 bytes!

Very well done @Goodwell.

I will share adapted to XA assembler sources and they should be usable for any other 8-bit platform.

Thank you

How is XA Assembler different from ACME or more portable?

Looking forward to what you share

[Goodwell]

Super and very useful!
Will certainly use this.

Please let me know how you can make use of it.
Discord is also fine, email notifications don‘t seem to work for me here

[iss]

How is XA Assembler different from ACME or more portable?

Well, it's different...
If comparing with CA65 I would say it's more easy but honestly its 'cons' are more:
- no macroses;
- old and no real support;
- etc..
Historically, I'm using it last 15 years (almost every day ) and it's like habit for me
and no single bug in the generated code was found so far.
The most and the best software for Oric is written with XA, so no dilemma.

[Goodwell]

How is XA Assembler different from ACME or more portable?

Well, it's different...
If comparing with CA65 I would say it's more easy but honestly its 'cons' are more:
- no macroses;
- old and no real support;
- etc..
Historically, I'm using it last 15 years (almost every day ) and it's like habit for me
and no single bug in the generated code was found so far.
The most and the best software for Oric is written with XA, so no dilemma.

Good to know, thanks!

[Chema]

Macros can be done with the preprocessor (via #defines, I mean) to some extent.

I miss some kind of instruction to create data with patterns for tables and repetitive code (when unrolling loops).

And I could not live without the way it handles scopes, using .( and .), globals with + and so on. But I am aware the scope and label management in ca65 is now really advanced and has many nice features.

[Dbug]

We should probably have a separate thread for this discussion, but at some point we will probably need to address the elephant in the room: The C compiler of the OSDK was nice back in 1995, but now in 2025 it is a real hindrance and will have to be replaced... which most probably will mean replacing XA by something else that plays nicely with the compiler, which means all the sample code and existing code will become incompatible.

So I guess a OSDK 2.0 will not have XA anymore, just not sure what it will be.

[iss]

And here come the big surprise - how precise are the Oric emulators
Real Oric + LOCI: 17270.797 msec
CLKSignal: 17270.797 msec - perfect (Thanks @ThomH).
JOric: 17270.797 msec - perfect (Very well done @dreamseal).
MAME: 17270.453 msec - emulation is bit faster.
Oricutron: 17308.765 msec - emulation is slower.

Well, this actually turned out to be a huge problem which took me last week almost 24/7 coding.
I had to resurrect my emulator emul8 ... and the new player enters the race:

The high score table:

Code: Select all

========================================
  Real Oric + LOCI:     17270.797 msec
----------------------------------------
  emul8                 17270.797 msec - perfect @iss
  CLKSignal:            17270.797 msec - perfect @ThomH
  JOric:                17270.797 msec - perfect @dreamseal
  MAME:                 17270.453 msec - faster.
  Euphoric:             17272.867 msec - slower.
  Oricutron:            17308.765 msec - slower.

Тhe obvious conclusion:
If you want a good emulator use one which emulates on single cycle level instead of single instruction (period).

So, back to original topic 'QR code generation':
Thanks to @Goodwell we have lightning fast runtime QR generator, I'll post the adapted sources for XA asap.
The previous implementation in C (qrgen-0.2) is very good for tests and benchmarks because it uses VIA timer and 6502's BCD arithmetic - I will open a new topic where we can discuss and compare Oric emulators, C compilers, etc.

[Dbug]

So, is the problem miscalculation of clock cycles, or is it how fast the emulation runs compared to actual physical time?

[iss]

So, is the problem miscalculation of clock cycles, or is it how fast the emulation runs compared to actual physical time?

The problem is how Oric (or any other machine) is emulated.
If emulation is done on whole 6502 instruction then the exact moment of the VIA's T1 IRQ is missed and the issue pops-up . When the emulation is done by single cpu cycle (or even half-cycle!) - results are equal to real Oric or close depending on how correct other components are implemented.

Side effect: for instance JSR $XXXX needs 6 cycles - in instruction mode you call emulation step only once, in cycle mode you should call emulation step 6 times - so, the first offers better performance for weak host system, the later better accuracy. Best choice to have both - like I do .

EDIT: @Dbug: I remember you have an IRQ test program, can you give a link to it and I'll include it as a 'standard' test together with DskTest, if you don't mind of course