Seems Shadow was annoyed that the site was put up so he placed the site back online.

The mirror was put up without the stylesheet (it's still that way), and I couldn't stand to see it looking like that; it reflects badly on what few HTML skills I have. So I put my own copy back online. Compare the two, you'll see what I mean.

Out of all the people who sucked down that entire site, it took this long for someone to put up a mirror... and then without the stylesheet? Jeez guys, it's not rocket science.

_________________"...and all watched over by machines of loving grace."

I discovered (via Greg from CommodoreServer.com) an issue whereby Kipper BASIC would report (via ER%) a 'no such listener' error ($88, 136 decimal) on every TCPSEND or POLL after any UDP packet is received. On a typical LAN there is a lot of UDP broadcast packets (e.g. anything requesting an address via DHCP, plus regular 'host announcements' from windows boxes), and these were all resulting in Kipper BASIC reporting errors.

Greg kindly reported another bug, which is fixed in the attached version 1.21

This bug (which would have been introduced when I made PING a function as well as a keyword) meant in very specific situations, variable arithmetic went haywire.

It seems to trigger the bug, you needed to be adding to a variable a constant that was equal to the current value of the variable. i.e.

X=X+1 would trigger the bug if (and only if) X was 1 originally. X%=X%+3 would also trigger the bug if X% held the value 3. When the bug occured, the result of the addition would always be 12087 if using an integer variable (e.g. X% ) or 2.95652446E-25 if using floating point variables (e.g. X)

Root cause was I had copied some code out of the BASIC 'get arithmetic element' routine ($AE86) like this: lda $00 ;<--------- set accumulator to value of memory location $00, which would usually be $2F sta $0D ;set string flag to not string

when it should be this: lda #$00 ;<--------- set accumulator to $00 sta $0D ;set string flag to not string

I don't quite understand why the impact of this bug was so low, i.e. why the current value of the variable changed whether the addition got messed up or not. Anyway, 1 bug down, who knows how many more to go

I don't quite understand why the impact of this bug was so low, i.e. why the current value of the variable changed whether the addition got messed up or not.

Interesting one Perhaps the low impact is because you're only setting a flag and depending on how it is interpreted, things may go wrong or not? Good job finding it though. Bugs like that tend to be tricky

Following some bug reports and feature requests, here's v1.27changes are:- fixed a bug that lead to eventual memory corruption and crashes when AUTOEXEC.BAS was automatically loaded and executed- as well as IN$ (which can hold up to 255 bytes of data), POLL and TCPSEND now also set IP% (which is a pointer to a buffer) and IL% (which is the length of data in that buffer). A single TCP packet encapsulated in an ethernet frame can have up to ~1480 bytes, and if a packet arrived with more than 255 bytes of data in it, some of it was getting lost. IP% and IL% allow access to all the data, albeit in a cumbersome way.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum